Configure Dampening Settings for an SNMP Trap Incident

For information about each SNMP Traps tab: See Also

NNMi enables you to delay (dampen) the following for an incident configuration:

• Appearance within Incident views in the NNMi Console
• Execution of Incident Actions

• Execution of Diagnostics

  Requires Network Node Manager iSPI Network Engineering Toolset Software (NNM iSPI NET) and requires installation of a Diagnostic Server.

You can configure Dampening settings based on Interface Group, Node Group, or default Dampening settings. NNMi applies your Dampening settings in the following order. Only the first match applies.

1. Interface Group (SNMP Trap Configuration Form: Interface Settings tab)
2. Node Group (SNMP Trap Configuration Form: Node Settings tab)
3. Dampening configuration settings without specifying an Interface Group or Node Group (SNMP Trap Configuration Form: Dampening tab)

When using Dampening configuration, note the following:  

• For all Incident Configurations except Deduplication and Rate Incidents, if the dampened Incident is Closed before the Dampen Interval has passed, NNMi deletes the Incident. If the Incident is the Root Cause Incident, NNMi also deletes any Child Incidents

  Note NNMi administrators can view the number of incidents Closed and deleted while dampened. Access the Help → System Information → Health tab, click the View Detailed Health Report button, and search for the word dampened.

• For all Incident Configurations except Deduplication and Rate Incidents, if the dampened Incident is Closed before the Dampen Interval has passed, NNMi deletes the Incident. If the Incident is the Root Cause Incident, NNMi also deletes any Child Incidents.
• NNMi always retains the Parent Deduplication or Rate Incident even If its Child Incidents are Closed within the Dampen Interval and subsequently deleted. See Correlate Duplicate Incidents (Deduplication Configuration) and Track Incident Frequency (Rate: Time Period and Count) for more information about Duplicate and Rate Correlation incidents.
• Any Deduplication and Incidents that have Child Incidents inherit the Dampening settings from their Correlated Children.

• If an incident is a Root Cause Incident and a Child Incident's Dampen Interval is less than the Parent Incident's Dampen Interval, NNMi holds any Child Incidents until the Dampen Interval for the Parent Incident has passed or until the Parent Incident is Closed and subsequently deleted.

• To make sure NNMi handles both Incidents in a Pairwise Configuration the same, configure the same Dampen Interval for each Incident in a Pairwise Incident Configuration.

• After the Dampen Interval has passed, NNMi changes the Lifecycle State to REGISTERED.

• You can use a Payload Filter to fine tune the incidents you want to dampen.

When configuring Interface Settings, Node Settings, or other Suppress Configuration, Enrich Configuration, or Dampening configuration settings for an incident, you can specify a Payload Filter. Payload Filters enables you to use the data that is included with any of the following items before they are stored as incidents in NNMi:

• Traps generated from an SNMP agent
• Syslog Messages
• Management incidents that are generated by NNMi

Examples of the type of data that can be used as a Payload Filter include SNMP trap varbind names and values as well as Management Event CIA (Custom Incident Attribute) names and values. For example, you might want NNMi to dampen an incident based on a particular status change notification trap and participation within a specified Node Group or Interface Group. To do so, you would first specify participation in the Node Group or Interface Group for the trap you want to dampen. You would also specify a Payload Filter that includes the name of the trap varbind that stores the status information as well as the status change value string of interest.

See Configure Incident Dampening Settings for an Interface Group (SNMP Trap Incident) for information about how to configure Dampening settings for an Interface Group with or without a Payload Filter.

See Configure Incident Dampening Settings for a Node Group (SNMP Trap Incident) for more information about how to configure Dampening for a Node Group with or without a Payload Filter.

To configure Dampening settings for an incident using a Payload Filter without an Interface Group or Node Group Filter:

1. Navigate to the SNMP Trap Configuration form:

   1. From the workspace navigation panel, select the Configuration workspace.
   2. Expand the Incidents folder.
   3. Select SNMP Trap Configurations.
   4. Do one of the following:
   1. To create a configuration, click the New icon, and continue.
   2. To edit configuration, select a row, click the  Open icon, and continue.
   3. To delete a configuration, select a row and click the  Delete icon.
2. Select the Dampening tab.
3. Provide the required information (see table)
4. Click  Save and Close to save your changes and return to the previous form.

Dampening Attributes

Name	Description
Enable	Use this attribute to temporarily disable an incident's Dampening settings: Disable  = Temporarily disable the selected configuration. Enable  = Enable the selected configuration.
Hour	Specifies the number of hours to be used for the Dampen Interval.
Minutes	Specifies the number of minutes to be used for the Dampen Interval.
Seconds	Specifies the number of seconds to be used for the Dampen Interval.
Payload Filter	[ This Snippet contains a table with a hard-coded column width <col style="width: 77px;" /> on the first column. Do not remove the setting. ] The Payload Filter Editor enables you to create expressions that further refine the filters used to select the incidents to be suppressed, enriched, or dampened. Make sure to design any complex Payload Filters offline as a Boolean expression first. This method can help to minimize errors when entering your expressions using the Payload Filter editor. When creating a Payload Filter, note the following: Payload Filter expressions for the like and not like operators use the syntax defined for java regular expressions (java.util.regex Pattern class). You must use a ciaName that already exists in the trap or event you are configuring. Each set of expressions associated with a Boolean Operator is treated as if it were enclosed in parentheses and evaluated together. View the expression displayed under Filter String to see the logic of the expression as it is created. The AND and OR Boolean Operators must contain at least two expressions as shown in the example below. The following example filters incidents on voltage state: AND     ciaName = .1.3.6.1.4.1.9.9.13.1.2.1.7     ciaValue = 5 NNMi evaluates the expression above as follows: (ciaName = .1.3.6.1.4.1.9.9.13.1.2.1.7 AND ciaValue = 5) NNMi finds all incidents with a varbind .1.3.6.1.4.1.9.9.13.1.2.1.7 value of 5. Note When you use ciaName and ciaValue in a Payload Filter, you must enter the ciaName and ciaValue as a pair as shown in the preceding example. The placement of your cursor and the subsequent text that is selected is important when performing operations using the Payload Filter Editor. For example, you append to, replace, or change the indentation of the expression that is selected. The placement of your cursor and the subsequent text that is selected is especially important when adding your Boolean operators. You can include more than one varbind in the same Payload Filter expression as shown in the following example: ((ciaName like \Q.1.3.6.1.4.1.9.9\E.* AND ciaValue = 25) AND (ciaName like \Q.1.3.6.1.2.1.2.2.1.1.3\E.* AND ciaValue = 3)) In this example, a given trap must meet each of the following criteria: Contain a varbind whose Object Identifier (OID) matches the regular expression \Q.1.3.6.1.4.1.9.9\E.* and has a value of 25. Contain a varbind whose OID matches the regular expression \Q.1.3.6.1.2.1.2.2.1.1.3\E.* and has a value of 3. Payload Filter Editor Settings Attribute Description Attribute The attribute name on which NNMi searches. Filterable attributes include the following: ciaName ciaValue Note When you use ciaName and ciaValue in a Payload Filter, you must enter the ciaName and ciaValue as a pair. For example: (ciaName =.1.3.6.1.4.1.9.9.13.1.2.1.7 ) AND ( (ciaValue = 4) OR ( ciaValue = 5)) is not supported. Operator Valid operators are described below. = Finds all values equal to the value specified. Click here for an example. Example: ciaName=.1.3.6.1.4.1.9.9.13.1.2.1.7 matches any incident that contains a varbind with the name value of .1.3.6.1.4.1.9.9.13.1.2.1.7. != Finds all values not equal to the value specified. Click here for an example. Example: ciaName! = .1.3.6.1.4.1.9.9.13.1.2.1.7 matches any incident that contains a varbind with a name value other than 1.3.6.1.4.1.9.9.13.1.2.1.7. < Finds all values less than the value specified. Click here for an example. Example: ciaValue < 6 matches any incident that contains a varbind with a value less than 6. <= Finds all values less than or equal to the value specified. Click here for an example. Example: ciaValue <= 6 matches any incident that contains a varbind with a value less than or equal to 6. > Finds all values greater than the value specified. Click here for an example. Example: ciaValue > 4 matches any incident that contains a varbind with a value greater than 4. >= Finds all values greater than or equal to the value specified. Click here for an example. Example: ciaValue >= 4 matches any incident that contains a varbind with values greater than or equal to 4. between Finds all values equal to and between the two values specified. Click here for an example. Example: ciaValue between matches any incident that contains a varbind value equal to or greater than 1 and equal to or less than 4. Note As shown in the example, each value must be entered on a separate line. in Finds any match to at least one value in a list of values. Click here for an example. Example: ciaValue in matches any incident with a varbind value of either 4 or 5. Note As shown in the example, each value must be entered on a separate line. NNMi displays the list of attributes using comma-separated values enclosed in parentheses, for example (4, 5). However, the comma-separated list is used only for display purposes. The actual delimiter is the new line. is not null Finds all non-blank values. Click here for an example. Example: ciaValue is not null matches any incident with a varbind that contains a value. is null Finds all blank values. Click here for an example. Example: ciaValue is null matches any incident with a varbind that does not contain a value. like Finds matches using the syntax defined for java regular expressions. See the Pattern (Java Platform SE6) API documentation at: http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html for more information. Click here for more information. The period asterisk (.*) characters mean any number of characters of any type at this location. The period (.) character means any single character of any type at this location. Note To include literal string values in the Value attribute, enclose the string value in \Q<literal_value>\E as shown in the Examples listed below. Example: ciaName like \Q.1.3.6.1.4.1.9.9\E.* matches any incident that contains a varbind name value that begins with 1.3.6.1.4.1.9.9 and (optionally) ends with any number of characters. ciaValue like .*Chicago.* finds all traps or events that contain a varbind value that includes the string Chicago. not between Finds all values except those between the two values specified. Click here for an example. Example: ciaValue not between 5 8 matches an incident that contains a varbind with the values less than 5 or greater than 8 . not in Finds all values except those included in the list of values. Click here for an example. Example: ciaValue not in matches any incident that contains a varbind with values other than 1 and 2. Note As shown in the example, each value must be entered on a separate line. NNMi displays the list of attributes using comma-separated values enclosed in parentheses, for example, (1, 2). However, the comma-separated list is used only for display purposes. The actual delimiter is the new line. not like Finds all that do not have the values specified using the syntax defined for Java regular expressions. See the Pattern (Java Platform SE6) API documentation at: http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html for more information. Click here for an example. The period asterisk (.*) characters mean any number of characters of any type at this location. The period (.) character means any single character of any type at this location. Note To include literal string values in the Value attribute, enclose the string value in \Q<literal_value>\E as shown in the Examples listed below. Example: ciaName not like \Q.1.3.6.1.4.1.9.9\E.* matches any incident that contains a varbind name value that does not begin with .1.3.6.1.4.1.9.9 and (optionally) ends with any number of characters. ciaValue not like .*Chicago.* finds all traps or events that do not contain a varbind value that includes the string Chicago. Value The value for which you want NNMi to search. Note the following: The values you enter are case sensitive. NNMi displays a variable number of value fields depending on the Operator selected. For example, the between Operator causes two value fields to be displayed. The between, in and not in operators require that each value be entered on a separate line. Payload Filter Editor Buttons Button Description Append Appends the current expression (Attribute, Operator,and Value) to the selected expression already included in the filter string. Insert Inserts the current expression (Attribute, Operator,and Value) in front of the cursor location within the Filter String. Replace Replaces the selected expression with the expression displayed in the Attribute, Operator, and Value fields. AND Inserts the AND Boolean Operator in the selected cursor location. Note View the expression displayed under Filter String to see the logic of the expression as it is created. OR Inserts the OR Boolean Operator in the current cursor location. Note View the expression displayed under Filter String to see the logic of the expression as it is created. NOT Can be used in any part of the Filter String to specify that NNMi should exclude interfaces with values that pass the expression that immediately follows the NOT. For example, when evaluating the following expression, NNMi includes interfaces with (interface description) ifDesc containing VLAN, and excludes any Interfaces that have VLAN10 for the (interface name) ifName value:  (ifDesc like VLAN AND NOT (ifName=VLAN10))  Note View the expression displayed under Filter String to see the logic of the expression as it is created. EXISTS Used for filters that include Capabilities or Custom Attribute names and values in the Filer String. Indicates that you want NNMi to consider interfaces that have Capabilities or Custom Attributes when evaluating the Filter String. Tip When creating complex Filter Strings that include customAttrName and customAttrValue pairs as one component of an "or" statement, to prevent NNMi from excluding Nodes that have zero Custom Attributes, use EXISTS or NOT EXISTS criteria for the customAttrName and customAttrValue pair definitions. Otherwise Nodes that do not have any Custom Attributes are automatically excluded even if they have values that pass other aspects of your filter. For example, when evaluating the following Filter String, NNMi includes interfaces with (interface description) ifDesc containing VLAN, as well as any Interfaces Custom Attribute Role value is LAN Connection to Oracle Server:  (ifDesc like VLAN OR EXISTS((customAttrName=Role AND customAttrValue=LAN Connection to Oracle Server))) Note View the expression displayed under Filter String to see the logic of the expression as it is created. NOT EXISTS Used for filters that include Capabilities or Custom Attribute names and values in the Filer String. Indicates that you want NNMi to consider interfaces that do not have any Capabilities or Custom Attributes when evaluating the Filter String, but exclude the interfaces that match the expression that follows the NOT EXISTS. Tip When creating complex Filter Strings that include customAttrName and customAttrValue pairs as one component of an "or" statement, to prevent NNMi from excluding Nodes that have zero Custom Attributes, use EXISTS or NOT EXISTS criteria for the customAttrName and customAttrValue pair definitions. Otherwise Nodes that do not have any Custom Attributes are automatically excluded even if they have values that pass other aspects of your filter. For example, when evaluating the following expression, NNMi includes interfaces with (interface description) ifDesc containing VLAN, and excludes any Interfaces that have the Custom Attribute Role and that Role value is LAN Connection to Oracle Server:  (ifDesc like VLAN OR NOT EXISTS((customAttrName=Role AND customAttrValue=LAN Connection to Oracle Server))) Note View the expression displayed under Filter String to see the logic of the expression as it is created. Delete Deletes the selected expression. Note If the Boolean Operator is selected, the Payload Filter Editor deletes all expressions associated with the Boolean Operator.