11.8 Filtering Service Model Alarms

Administrators can create alarm filters and filter groups and apply them to service models or metamodel classes. Instance-level filters always take priority over class-level filters. These filters determine the subset of alarms that users can view in the Operations Center console and Dashboard.

IMPORTANT:Alarm filtering occurs on the client side. Any server side scripts that perform the getAlarms function on an element with alarm filters returns all alarms, unfiltered.

The following sections explain how to use filtering for Service Model alarms:

11.8.1 Creating Alarm Filters

Filters for service model alarms are created independently of an element and are then applied to service models. Because service model alarm filters are not attached to specific element on creation, a sampling of alarm columns from a non-related element are used to build the filter before it is applied.

The rules used for alarm filters that are applied to service models and metamodel classes are the same as those described earlier in the section. For details on the appropriate usage and syntax of conditional statements in a filter, see Creating an Alarm Filter in the Operations Center 5.5 User Guide and see the table in Step 8 of the Creating an Alarm Filter procedure.

To create an alarm filter:

  1. In the Explorer pane, expand Administration > Server > Alarm Filtering.

  2. Right-click Alarm Filters, then select Create Alarm Filter. The Alarm Filter dialog box opens.

  3. Click Browse to select an element that currently has alarms.

    This is used to gather a sample list of alarm column names which can prepopulate the alarm column field for defining the filter. We recommend selecting an element that has the widest wide-range of alarm columns.

  4. Select the element, then click OK.

    Selectors in the Alarm Filter dialog box activate.

    Operations Center determines the alarm column names and types are available based on the alarms of the selected element.

  5. Specify a name for the new filter in the Filter Name field.

  6. Do one of the following to determine the type of match: Select the Match All radio button to determine if an alarm must match any or all of the condition statements in order to be selected.

    • Select the Match any of the following radio button to match one or more condition expressions. Selecting this option joins more than one statement with an OR operator.

    • Select the Match all of the following radio button to match all of the condition expressions. Selecting this option joins more than one statement with an AND operator.

    • Select the Custom boolean expression radio button to join the statements using a custom boolean expression.

  7. Click Add.

    A blank row displays for defining a filter statement.

  8. Click the first drop-down list, then select the alarm column name to match in the filter.

    The list options available depend on the selected element in see the table in Step 8 of the Creating an Alarm Filter procedure in the Operations Center 5.5 User Guide.

    For example, select Date/Time if the filter searches alarms based on the date and time they were received:

  9. Select comparison operators and specify match criteria using the other fields in the row. The list or options vary depending on the type of alarm column selected from the first drop-down list.

    For more information, see the table in Step 8 of the Creating an Alarm Filter procedure in the Operations Center 5.5 User Guide.

  10. To add an additional filter expression, click Add.

  11. If the Custom boolean expression radio button was selected in Step 6, specify a boolean expression using alarm expression ids to indicate how the condition statements are to be applied:

    • Expression ids display in the front of each condition statement.

    • Use AND to join two expressions.

    • Use OR to match any of two expressions.

    • Use NOT to not match an expression.

    • The boolean expression is not case-sensitive. Not all alarm expressions must be applied as boolean expressions can be formed in a way that ignores an expression. For example, if the following expression is used, (AF1 OR AF2) AND (NOT AF4), then AF3 would be ignored.

    • In the figure below, the filter allows alarms no older than 24 hours with a severity of CRITICAL, MAJOR, MINOR and UNKNOWN.

  12. (Conditional) To deactivate the filter upon logout from the Operation Center console, select the Deactivate this filter on logout check box. This option only applies when filter is applied to non-Service Model elements.

    To leave the filter activated from session to session, leave the check box deselected.

    Deactivating filters upon logout ensures that all alarms display after the next login.

    If filters remain active upon logout, the active filters apply upon login and only the selected alarms display in the Alarms view. Problems might arise from not realizing that all alarms are not displayed.

  13. Click OK when all filter criteria has been defined.

11.8.2 Editing Alarm Filters

Because service model alarm filters are not attached to specific element on creation, it is necessary to obtain another sampling of alarm columns to prepopulate fields when you are editing alarm filters.

To edit an alarm filter:

  1. In the Explorer pane, expand Administration > Server > Alarm Filtering > Alarm Filters.

  2. Right-click the desired filter, then select Properties. The Properties dialog opens.

  3. Click Alarm Filter to open the filter definition.

  4. To edit the alarm column for the existing filter expressions or if planning to add additional expressions, do the following:

    1. Click Sample to select an element that currently has alarms.

      This is used to gather a list of alarm column names which prepopulate the alarm column field for defining the filter. We recommend selecting an element under Service Models that has a wide-range of alarm columns.

    2. Select the element, then click OK.

      Selectors in the Alarm Filter dialog box activate.

      Operations Center determines the alarm column names and types are available based on the alarms of the selected element.

  5. To add an additional filter expression, click Add.

    For details on adding filters as well as the appropriate usage and syntax of conditional statements in a filter, see Creating an Alarm Filter in the Operations Center 5.5 User Guide.

  6. Click OK.

11.8.3 Creating Filter Groups

Use alarm filter groups to apply multiple filters to a service model. Note that all filters in a group are applied using the AND operator, meaning an alarm must meet the conditions stated by all filters in the group in order to be displayed in the Alarms view.

To create an alarm filter group:

  1. In the Explorer pane, expand Administration > Server > Alarm Filtering.

  2. Right-click Alarm Filter Groups, then select Create Alarm Filter Group to open the Alarm Filter Group dialog box:

  3. In the Name field, specify a name for the new group.

  4. Select one or more alarm filters in the Available Alarm Filters field, then click Add to add the filters to the group.

    The order of filters is significant, as filters are processed from the top down. Only the alarms that pass the first filter are tested by the second filter, and so on.

    The selected filters move to the Selected Alarm Filters field.

  5. For each selected filter, decide to include or exclude matching alarms from the Alarms view:

    • To show alarms selected by the filter, click the associated Type drop-down list, then select Include.

    • To hide alarms selected by the filter, click the associated Type drop-down list, then select Exclude.

      Alarms selected by the filter are not displayed in the Alarms view.

  6. If there is a need to stop using a filter temporarily, unmark the Active check box.

    By default, defined filters are active, meaning they are applied to the Alarms view.

  7. When finished, click Create.

11.8.4 Applying Filters to Service Models

Alarm filters can be applied at the class-level, or with an element-level filter or filter group. Instance-level filters always take priority over class-level filters. When you create a class-level filter, it applies to all elements in the class, except the elements that have their own filters/ filter groups. Class-level filters are ignored by these elements.

You can ignore the class-level filter even when there is no element-level filter. Open the element’s Alarm Filtering property page, then select Ignore Class-Level Filters. For more information, see Section 11.8.5, Applying Filters to Element Classes.

Alarm filters and filter groups can be applied to any element in the Service Model hierarchy.

To apply server-side filters to elements under Service Models:

  1. Right-click an element in the Service Models hierarchy, then select Properties.

  2. In the left pane of the Properties window, click Alarm Filtering.

  3. Select either the Alarm Filter or Alarm Filter Group radio button:

  4. Select the filter or filter group from the drop-down list.

    If you select a filter, decide whether to include or exclude alarms that are collected by the filter. Include displays the alarms in the Alarms view; exclude prevents them from displaying.

    The Ignore Class-Level Filters option is relevant if alarm filters are applied to the element class (see the next section).

    This option is available only if there are no alarm filters or groups applied to the element on the Alarm Filtering property page shown above. Otherwise, the option is dimmed and cannot be selected. As stated earlier, when an element-level filter or filter group is applied, the class-level filter is ignored . If you do not want to apply the class filter to a specific element, select the Ignore Class-Level Filters check box.

    If you have already made a filter or filter group selection on the Alarm Filtering property page, click Clear and then you can select the Ignore Class-Level Filters check box.

  5. Click Apply.

11.8.5 Applying Filters to Element Classes

Alarm filters and filter groups can be applied to a class of elements. The filters are applied to all elements of the specified class. The exceptions are:

  • Ignore class-level filters is selected on an element’s Alarm Filters property page. For more information, see the previous section.

  • A filter (or filter group) is applied to an element. This filter takes priority over the class-level filter, which is ignored.

To apply a filter to a class:

  1. In the Explorer pane, expand Administration > Metamodel > Classes.

  2. Right-click a class, then select Properties.

  3. In the left pane of the Properties window, click Alarm Filtering.

  4. Select either the Alarm Filter or Alarm Filter Group radio button.

  5. Select the filter or filter group from the drop-down list:

  6. Decide whether to include or exclude alarms that are collected by the filter.

    Included alarms display the alarms in the Alarms view; excluded alarms do not display.

  7. Click Apply.

11.8.6 Clearing Filters from Elements

To clear a filter, open the Alarm Filtering property page for the Service Model element or class, then click Clear.

11.8.7 Giving Users View Permissions to Filters

Users must have a minimum of View permissions to the Alarm Filters and Alarm Filter Groups element in order for filtering to work. If a user does not have View permission, then the client session cannot obtain the filter definition from the server, and the user can view all unfiltered alarms.

The default Users group does have View permissions. You should consider granting View permissions to other affected user groups.

To view or edit group permissions:

  1. Select the Alarm Filters or Alarm Filter Groups element under Administration > Server > Alarm Filtering.

  2. Open the Portal view:

    Group permissions are listed in the Access Control pane.

11.8.8 Deleting Filters

When an alarm filter is deleted, the filter remains assigned to the service model. The service model is not scanned to remove any assignment of this alarm filter/filter group because of potential performance degradation. However, deleted filters are ignored during alarm processing.

These stale filter assignments are removed the next time the Alarm Filtering property page is opened. The element is updated and the deleted filter is removed. If a class-level filter exists, it is applied then.

To delete a filter or filter group:

  1. In the Explorer pane, expand Administration > Server > Alarm Filtering > Alarm Filters or Alarm Filter Groups.

  2. Right-click a filter or filter group, then select Delete Alarm Filter or Delete Alarm Filter Group.

11.8.9 Assigning Filters Using Scripts

In many situations, it more convenient to use scripts to assign alarm filters and filter groups. Examples include during SCM build jobs and environments where administration is automated through scripts.

To assign alarm filters and filter groups programmatically:

  1. In the script, use the following syntax:

    element._mosolSmaf = 'smafName'
    

    where the format of the smafName is one of the following:

    • AFG:AFG_name

      Assigns an existing alarm filter group to the service model.

    • AFI:AF_name

      Assigns an existing alarm filter and includes the filter results,

    • AFE:AF_name

      Assigns an existing alarm filter and excludes the filter results,

    The alarm filter and alarm filter group names must already exist in the system. They do not need to be URL encoded.

    Some examples:

    • Assume there is an alarm filter group named critical db apps and an alarm filter named hosts in domain X. The following function assigns the critical db apps alarm filter group to the element:

      element._mosolSmaf = 'AFG:critical db apps'
      
    • The following function assigns the hosts in domain X alarm filter to the element. The alarm filter is the Include type, meaning that alarms selected by the filter are displayed in the Alarms view:

      element._mosolSmaf = 'AFI:hosts in domain X'
      

      The above code assumes that the variable element is in scope.

      If you were to enter AFG:hosts in domain X in the script, it is an invalid value because there is a filter, but not a filter group named hosts in domain X. Similarly, AF:critical db apps is invalid because the AF prefix is invalid; only the AFG, AFI, and AFE prefixes are valid.