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