Share via

Alert Suppression (beginning)

  • Article

            Alert suppression is feature that allows for greater flexibility of alerts raised. So how was alert suppression feature designed? First we need to distinguish between types of alert that could be raised in Operations Manager 2007.

Monitor state change based alerts:

            This type of alert is always suppressed by monitor ID. This in reality means that there is just one alert per monitor as long as state of that particular monitor fits condition for alert creation. Suppression of this type is not customizable

Rule generated alerts:

            This type of alert is suppressed based on configuration defined for alert generating write action. Following is snippet of module definition and as expected, suppression is driven by tag “Suppression”.

<Configuration>

  <IncludeSchemaTypes>

    <SchemaType>System.Health.AlertSchema</SchemaType>

  </IncludeSchemaTypes>

  <xsd:element name="Priority">

    <xsd:simpleType>

      <xsd:restriction base="xsd:integer">

        <xsd:minInclusive value="0" />

        <xsd:maxInclusive value="2" />

      </xsd:restriction>

    </xsd:simpleType>

  </xsd:element>

  <xsd:element name="Severity">

    <xsd:simpleType>

      <xsd:restriction base="xsd:integer">

        <xsd:minInclusive value="0" />

        <xsd:maxInclusive value="2" />

      </xsd:restriction>

    </xsd:simpleType>

  </xsd:element>

  <xsd:element name="AlertName" type="xsd:string" />

  <xsd:element name="AlertDescription" type="xsd:string" />

  <xsd:element name="AlertOwner" type="xsd:string" />

  <xsd:element name="AlertMessageId" type="xsd:string" />

  <xsd:element name="AlertParameters" type="System.Health.AlertParameters" />

  <xsd:element name="Suppression" type="System.Health.Suppression" minOccurs="0" maxOccurs="1" />

  <xsd:element name="Custom1" type="xsd:string" />

  <xsd:element name="Custom2" type="xsd:string" />

  <xsd:element name="Custom3" type="xsd:string" />

  <xsd:element name="Custom4" type="xsd:string" />

  <xsd:element name="Custom5" type="xsd:string" />

  <xsd:element name="Custom6" type="xsd:string" />

  <xsd:element name="Custom7" type="xsd:string" />

  <xsd:element name="Custom8" type="xsd:string" />

  <xsd:element name="Custom9" type="xsd:string" />

  <xsd:element name="Custom10" type="xsd:string" />

</Configuration>

Where suppression type is defined as list of suppression values:

<xsd:complexType name="System.Health.Suppression">

  <xsd:sequence>

    <xsd:element name="SuppressionValue" type="xsd:string" minOccurs="0" maxOccurs="unbounded" />

  </xsd:sequence>

</xsd:complexType>

As we can see, there is a possibility for Alert suppression to be ignored causing new alert created each and every time. This is achieved when tag “Suppression” doesn’t exist in configuration for alert rule.

Default suppression using workflow id is to be used when tag “Suppression” exists with empty tag “SuppressionValue”. This is causing same behavior as described for alert generated by monitor state change then.

Customized suppression using hash of defined values with workflow id is to be used tag “Suppression” exists with non empty tag “SuppressionValue”. This for example allows for alert to be raised each and every time different description of event exists. It also disallows for suppression across workflows though.

Conclusion:

1. No tag Suppression

· Result:
Suppression is ignored and new alert is raised all the time

2. Empty tag Suppression

· Example:

 <Suppression></Suppression>

<Suppression/>

·  Result:Suppression is ignored and new alert is raised all the time

3. Empty tag SuppressionValue

· Example:

<Suppression>
<SuppressionValue></SuppressionValue>
</Suppression>

<Suppression>
<SuppressionValue/>
</Suppression>

· Result:Suppression is based on workflow ID which is same as suppression used for alert generated by monitor state change

4. Non empty tag SuppressionValue

· Example:

<Suppression>
<SuppressionValue>value</SuppressionValue>
</Suppression>

· Result:Suppression is based on the hash calculated from “value” + workflow ID

Comments

  • Anonymous
    February 07, 2008
    Hi, Is it possible to create a rule with suppression and an automatic reset after a certain time or after several events?

  • Anonymous
    February 12, 2008
    Automatic reset is possible when monitor generating alert is used. Unfortunately, suppression for such alert is not customizable at the moment, and alert is always suppressed based on monitor ID. This means that there is just one alert per health state. I believe, there could be also custom solution developed using DK connector approach, where such connecvtor "listens" to alert, "monitors" alert count and provides auto resolution of alert after threshold is reached ...

  • Anonymous
    April 23, 2009
    Are there any performance implications of using dynamic suppression value? Where: on client or server side?

  • Anonymous
    April 26, 2009
    Not really. Suppression value is calculated by runtime all the time and stored procedure in operational DB makes decision if it is update or insert.

  • Anonymous
    July 26, 2009
    Hi Marius Very useful information - just wondered if there was any way I could achieve the following: I have an application that logs fail codes to a log file such as fail_abc, fail_def, fail_ghi .. I can generate a rule to check for this with a contains fail criteria. But I can't see a way to suppress on contains fail. I know this can't be done via the GUI, but is there a way of putting an XPath Query into the <suppression value> field? Thanks Graham