Alert Rules

Applies To: System Center Operations Manager 2007

Alert rules create alerts in response to particular conditions detected in a data source. This is the same kind of alert that is created by a monitor when it changes state. Monitors and alert rules use the same data sources and typically the same kind of logic for determining whether an error has occurred.

A monitor that creates an alert is generally preferred over an alert rule identifying the same issue for the following reasons:

• Monitors set a health state on the target object in addition to creating the alert. This identifies the category of the detected problem, the application component affected, and its effect on the overall health of the application. The health state is also recorded for availability reports that provide historical record of the availability of the application.

• Alerts created by monitors can be automatically resolved when the application returns to a healthy state. Alerts created by rules cannot be automatically resolved because there is no method of determining the healthy state.

The situations when a rule should be used instead of a monitor to create an alert are as follows:

• The problem being detected does not relate to the health of the application. For example, an application may perform an automated nightly backup. If the backup fails, then an alert should be created to inform users of this condition. The application though is still completely healthy and should not record a negative health state.

• A monitor is cannot determine when the detected problem was resolved. One of the options to this condition is to use a rule to create an alert instead of a monitor. This situation is discussed with additional options in the Event Monitors section of this guide.

Event Alert Rules

Alert rules can be created for each event data source. The criteria that is specified to determine when an alert should be created is the same as the criteria for a state change in the event monitors.

Performance Alert Rules

The Authoring Console provides no wizards for creating an alert rule based on a performance counter. A monitor should be used instead because a success condition is usually detectable from a performance counter and is usually related to some health state of the target class. Alert rules based on a performance counter can be created, although they must be done with a custom rule.

Scripting Alert Rules

The Authoring Console provides no wizards for creating an alert rule based on a script. A monitor should be used instead because a script will typically provide a return value for both and error and a healthy state in such a way that a success condition is usually detectable and related to some health state of the target class. Alert rules based on a script can be created, although they must be done with a custom rule.

Alerts from Rules

Alert Name

The name of the alert is a single line of static text and cannot include any variables.

Alert Description

The alert description may have several lines of text that includes static text or variables. The most common kind of variable in the alert description will be $Data variables to include different information from the rule’s data source in the description of the alert. The properties that are available will depend on the kind of data source being used. Each section of Data Sources includes a list of the properties available for different data sources. The following table provides syntax and examples of variables in rule alerts created from different data sources:

Priority and Severity

The Alert severity defines the alert as either Information, Warning, or Critical. This severity does not have to match the severity of the health state triggering the alert. The severity of the alert is identified by an icon in the Operations console and is used by views and notification subscriptions. The alert priority is inaccessible in the Operations console but is used primarily for notification subscriptions.

Alert Suppression

Alert suppression refers to logic that is defined on alert rules to suppress the creating an alert when a corresponding alert is still open. This prevents alert storms where multiple alerts are created for the same issue. Because the issue has already been identified with an open alert, creation of additional alert creates unnecessary noise with minimal value. When the condition for an alerting rule is met but an existing alert is already open, instead of creating an additional alert suppression will increase the repeat count of the existing alert.

In order to define suppression on an alerting rule, the fields must be specified that identify a matching alert. Before an alerting rule creates a new alert, it will check whether an open alert exists with values for the fields that are defined for suppression that match the fields of the new alert. If an alert with matching values for each of these fields is open, then a new alert is not created.

The minimum number of fields that uniquely identify the alert should be specified for alert suppression. This is typically the computer name in addition to the fields used for the criteria of the rule. For example, suppression on event rules can frequently be achieved by using the following fields:

• Logging Computer

• Event Source

• Event Number

If the rule is targeted at a class that has multiple instances on the agent, however, then a parameter might be required to uniquely identify the event in the criteria of the rule. If this is the case, then the same parameter should be specified in the alert suppression.

Automatic Alert Resolution

Automatic resolution cannot be performed on alerts that are created from a rule since a rule has no mechanism for determining that