System.Health.GenerateAlert

  • Article

Applies To: Operations Manager 2007 R2

The System.Health.GenerateAlert is a write action module type that accepts any type of data. A module of this type is used in a rule to generate an alert.

Usage

Use this module within a workflow such as a rule or a monitor in order to generate an alert.

Type Definition

<WriteActionModuleType ID="System.Health.GenerateAlert" Accessibility="Public" Batching="false">
  <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" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="AlertDescription" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="AlertOwner" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="AlertMessageId" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="AlertParameters" type="System.Health.AlertParameters" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Suppression" type="System.Health.Suppression" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom1" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom2" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom3" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom4" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom5" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom6" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom7" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom8" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom9" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="Custom10" type="xsd:string" minOccurs="0" maxOccurs="1"/>
  </Configuration>
  <OverrideableParameters>
    <OverrideableParameter ID="Priority" ParameterType="int" Selector="$Config/Priority$"/>
    <OverrideableParameter ID="Severity" ParameterType="int" Selector="$Config/Severity$"/>
  </OverrideableParameters>
  <ModuleImplementation Isolation="Any">
    <Composite>
      <MemberModules>
        <ConditionDetection TypeID="System.Health.GenericAlertMapper" ID="Mapper">
          <Priority>$Config/Priority$</Priority>
          <Severity>$Config/Severity$</Severity>
          <ManagedEntityId>$Target/Id$</ManagedEntityId>
          <AlertName>$Config/AlertName$</AlertName>
          <AlertDescription>$Config/AlertDescription$</AlertDescription>
          <AlertOwner>$Config/AlertOwner$</AlertOwner>
          <AlertMessageId>$Config/AlertMessageId$</AlertMessageId>
          <AlertParameters>$Config/AlertParameters$</AlertParameters>
          <Suppression>$Config/Suppression$</Suppression>
          <WorkflowId>$MPElement$</WorkflowId>
          <Custom1>$Config/Custom1$</Custom1>
          <Custom2>$Config/Custom2$</Custom2>
          <Custom3>$Config/Custom3$</Custom3>
          <Custom4>$Config/Custom4$</Custom4>
          <Custom5>$Config/Custom5$</Custom5>
          <Custom6>$Config/Custom6$</Custom6>
          <Custom7>$Config/Custom7$</Custom7>
          <Custom8>$Config/Custom8$</Custom8>
          <Custom9>$Config/Custom9$</Custom9>
          <Custom10>$Config/Custom10$</Custom10>
          <ManagementGroupName>$Target/ManagementGroup/Name$</ManagementGroupName>
        </ConditionDetection>
        <WriteAction TypeID="System.Health.PublishAlert" ID="WA"/>
      </MemberModules>
      <Composition>
        <Node ID="WA">
          <Node ID="Mapper"/>
        </Node>
      </Composition>
    </Composite>
  </ModuleImplementation>
  <InputType>System!System.BaseData</InputType>
</WriteActionModuleType>

Parameters

The System.Health.GenerateAlert module supports the following configuration parameters:

Parameter Type Description

Priority

Integer (0 to 2)

Specifies the priority (low, medium, high) for the alert.

Severity

Integer (0 to 2)

Contains severity (information, warning, error) for the alert.

AlertName

String

Deprecated – use AlertMessageId instead.

AlertDescription

String

Deprecated – use AlertMessageId instead.

AlertOwner

String

Contains the owner for the alert. This parameter sets the initial owner, but it can be changed by a user when the alert is generated.

AlertMessageId

String

Contains up to 10 alert parameters that are used to populate the alert description.

AlertParameters

System.Health.AlertParameters

Contains up to 10 alert parameters that are used to populate the alert description.

Suppression

System.Health.Suppression

Defines how multiple alerts from the same rule are suppressed.

Custom1

String

Specifies the value for custom alert field 1.

Custom2

String

Specifies the value for custom alert field 2.

Custom3

String

Specifies the value for custom alert field 3.

Custom4

String

Specifies the value for custom alert field 4.

Custom5

String

Specifies the value for custom alert field 5.

Custom6

String

Specifies the value for custom alert field 6.

Custom7

String

Specifies the value for custom alert field 7.

Custom8

String

Specifies the value for custom alert field 8.

Custom9

String

Specifies the value for custom alert field 9.

Custom10

String

Specifies the value for custom alert field 10.

All parameters are optional, except Priority and Severity. However, either AlertName or AlertMessageId must be specified. Priority and Severity are the only fields that are defined as overridable in the module type.

Severity

Severity defines the alert severity and can be one of the following values:

  • 0 - Information

  • 1 - Warning

  • 2 – Critical

Priority

Priority defines the alert priority and the mapping, and it can be one of the following values:

  • 0 - Low

  • 1 - Medium

  • 2 – High

The default Active Alerts view in the Operations console does not show the priority of the alert, but you can add this column by personalizing the view if required.

Alert Owner

The AlertOwner parameter is used to set an owner for the alert. The meaning and possible values for this field are specific to a customer environment. It can be set at authoring time as required, but often it is omitted, especially for management packs that are shipped to other customers. Alert owner is an available property on the generated alert that can be set using the Operations console after an alert is generated.

AlertMessageID

The AlertMessageId parameter references a valid string resource element in the same management pack in which the rule that is using this module type is defined. The string resource element is used so that an alert name and description can be assigned to the alert in a localizable manner. The following code shows an example configuration:

<AlertMessageId>$MPElement[Name="AuthorMPs.ModuleSamples.ApplicationX.AlertOnEvent101.AlertMessage"]$</AlertMessageId>

You must use the $MPElement reference syntax to refer to a valid string resource. Verification of the management pack fails if the string resource does not exist in the management pack. The corresponding string resource is defined in the Presentation section of the management pack as:


<StringResources>
  <StringResource ID="AuthorMPs.ModuleSamples.ApplicationX.AlertOnEvent101.AlertMessage"/>
</StringResources>

AlertParameters

The AlertParameters element is an optional element that consists of between one to 10 alert parameter elements. Alert parameters are used to build an alert description that uses $Data and $Target values. If the alert description contains only static data, this element is not required. The alert parameters are used with the string resource that is referenced in the AlertMessageId to create the alert text. An following example shows a set of parameters:


<AlertParameters>
  <AlertParameter1>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</AlertParameter1>
  <AlertParameter2>$Data/EventDisplayNumber$</AlertParameter2>
</AlertParameters>

The following example is for a rule that is targeted at an application hosted by a Windows-based computer and monitors the Windows event log. This set of alert parameters provides the name of the computer athat the alert is generated on and the event ID of the event that generated the alert. These parameters can be used to build the alert description by creating a display string for the string resource that was referenced in the AlertMessageId element of the module configuration.

<DisplayString ElementID="Microsoft.Samples.ApplicationX.AlertOnEvent101.AlertMessage">
  <Name>Application X Failure</Name>
  <Description>Critical failure in Application X running on computer {0}.  Event received was event ID: {1}</Description>
</DisplayString>

Substitution place holders are used to refer to the alert parameters that are defined in the module configuration. Alert parameter 1 replaces {0}; alert parameter 2 l replaces {1}. As many as ten alert parameters can be defined in the module configuration. The preceding example might result in a description such as:

Critical failure in Application X running on computer computer001.mydomain.com. Event received was event ID: 101

Alert parameters can be used only in the alert description, and cannot be used in the alert name.

Suppression

The Suppression element is used to control how alerts are suppressed, based on repeater trigger conditions. There are three possible options:

  • Do not suppress alerts and create a new alert for every occurrence of the trigger event.

  • Suppress to one alert per workflow instance; this creates a maximum of one alert for each monitored object of the class that the rule is targeted at. A new alert is not created until the open alert is resolved.

  • Suppress based on values in the data that trigger the alert; for example, event parameters.

To configure the module with no suppression, use an empty element. For example:

<Suppression/>

To suppress on workflow, the suppression element contains an empty SuppressionValue element as follows:

<Suppression>
  <SuppressionValue/>
</Suppression>

To suppress on some value in the data item that is passed to the module, you can specify one or more $Data references as suppression values. In the following example, a Windows event alert generating rule is configured to suppress alerts only if the first event parameter matches the previous data item that generated an alert:

<Suppression>
  <SuppressionValue>$Data/Params/Param[1]$</SuppressionValue>
</Suppression>

Custom Parameters

The custom parameters are used to store additional information in the alert properties. This information appears in the Operations console and can be used to store any data. The data can be static, or it can contain $Target and $Data references and be populated at run time.

The following example shows a configuration for Custom1:

<Custom1>$Target/Host/Property[Type='Windows!Microsoft.Windows.Computer']/NetworkName$</Custom1>

Custom alert parameters are often used when you are coding alerts for forwarding to a ticketing system, and they are implemented either as part of the rule definition or after the alert is received by an operator.

Composition

The System.Health.GenerateAlert module is a composite module that contains the following member modules:

Workflow Run Order Module Type Usage

1

System.Health.GenericAlertMapper

Maps the incoming data to an alert data type.

2

System.Health.PublishAlert

Writes the alert to the Operations Manager database.

None.

External Module References

None.

Remarks

The preferred way to generate alerts is by using monitors that monitor the state of a specific aspect of an application or component and an alert based on state changes. However, when no state can be inferred from a system event, alert generating rules can be used.

When repeat alerts are suppressed, the repeat count on the alert is incremented and can be seen in the alert properties page of the Operations console. Only the first data item that triggered the alert is saved as context, and further data items are not stored.

Suppression is in place only while the alert is open. After the alert is closed, a new alert is opened by the first event that matches the trigger conditions.

Sample

The following example shows an alert-generated rule that generates an alert when an event ID 101 is received from source EventCreate. The alert is suppressed on workflow. Two alert parameters are defined, and one custom field is set.

<Rule ID="Microsoft.Samples.AlertOnEvent101" Target="Microsoft.Samples.ApplicationX" Enabled="true">
  <Category>Custom</Category>
  <DataSources>
    <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.EventProvider">
      <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
      <LogName>Application</LogName>
      <Expression>
        <And>
          <Expression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type="String">PublisherName</XPathQuery>
              </ValueExpression>
              <Operator>Equal</Operator>
              <ValueExpression>
                <Value Type="String">EventCreate</Value>
              </ValueExpression>
            </SimpleExpression>
          </Expression>
          <Expression>
            <SimpleExpression>
              <ValueExpression>
                <XPathQuery Type="UnsignedInteger">EventDisplayNumber</XPathQuery>
              </ValueExpression>
              <Operator>Equal</Operator>
              <ValueExpression>
                <Value Type="UnsignedInteger">101</Value>
              </ValueExpression>
            </SimpleExpression>
          </Expression>
        </And>
      </Expression>
    </DataSource>
  </DataSources>
  <WriteActions>
    <WriteAction ID="GenerateAlert" TypeID="SystemHealth!System.Health.GenerateAlert">
      <Priority>0</Priority>
      <Severity>0</Severity>
      <AlertMessageId>$MPElement[Name="Microsoft.Samples.AlertOnEvent101.AlertMessage"]$</AlertMessageId>
      <AlertParameters>
        <AlertParameter1>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</AlertParameter1>
        <AlertParameter2>$Data/EventDisplayNumber$</AlertParameter2>
      </AlertParameters>
      <Suppression>
        <SuppressionValue/>
      </Suppression>
      <Custom1>$Target/Host/Property[Type='Windows!Microsoft.Windows.Computer']/NetworkName$</Custom1>
    </WriteAction>
  </WriteActions>
</Rule>

The StringResource element is defined as:

<StringResource ID="Microsoft.Samples.AlertOnEvent101.AlertMessage"/>

The display string for the StringResource element is defined as:

<DisplayString ElementID="AuthorMPs.Samples.AlertOnEvent101.AlertMessage ">
  <Name>Application X Failure</Name>
  <Description>Critical failure in Application X running on computer {0}.  Event received was event ID: {1}</Description>
</DisplayString>

Information

   

Module Type

WriteActionModuleType

Input Type

System.BaseData

Output Type

None.

Implementation

Composite

Library

System.Health.Library