Alert correlation rules

Alert correlation rules enable you to manually classify alerts into primary and secondary, and establish a relationship between them. Use alert correlation rules to group alerts that are related.

For example, if a server in your organization goes offline, you do not need to see additional alerts that show that the virtual machines or applications running on the server are also down. Instead, these additional alerts, or secondary alerts, are grouped under the root alert called the primary alert. You can see these grouped alerts in the alert console.

Note: Service Analytics provides alert groups for an automated correlation of events and alerts. These alert action rules give you full manual control of alert correlation. For more information on the service analytics feature, see Automated alert groups .

Primary and secondary alerts

  • A primary alert identifies the root cause of an event.
  • A secondary alert is another alert that the same event generates, but is considered less important than the primary alert.
The purpose of specifying secondary alerts is to identify which alerts to suppress, so you can reduce the amount of alert noise and focus on the primary alert. You are able to see both types of alerts, but the secondary alerts are grouped under the primary alert in the alert console view.
Figure 1. Correlated alerts grouped under the primary alert (Alerts Console)
Correlated alerts grouped under the primary

How primary and secondary alert action rules work

Primary and secondary alert action rules are simply filters that specify which kinds of alerts are classified as primary and which kinds are classified as secondary. The filter criteria runs against the Alert [em_alert] table.

An alert can belong to more than one group, but only one level of secondary alerts is allowed under a primary alert. For example, if secondary alert A is grouped under secondary alert B, both alerts become secondary alerts under the same primary alert. See alert hierarchy for more information.

Alert relationships

Alert correlation rules enable you to specify what type of relationship the primary and secondary alerts must have for the rule to match. These relationships depend on the relationships between the CIs in the CMDB:
  • No Relationship: Ignore the relationship when looking for a match.
  • Same CI or Node: Relate both alerts with the same CI. If the CI field is blank, then the alerts must have the same Node value.
  • Primary is Parent: The relationship is in the direction of parent (primary) to child, as described in the CI Relationship Types table [cmdb_rel_ci]).
  • Primary is Child: The relationship is in the opposite direction, child (primary) to parent, as described in the CI Relationships table [cmdb_rel_ci]).

When correlation rules run

Alert correlation rules run when an alert is created or reopened. The alert is checked to determine if it matches being primary or secondary.

When the primary alert severity is changed to Closed, the secondary alerts are also set to Closed unless they are part of other groups where the primary alert is not yet set to Closed.

Alert hierarchy

Only one level of secondary alerts is permitted. In situations where a secondary alert has its own secondary alert, the Event Management application flattens the hierarchy to preserve only two levels.

For example, assume alert A is the primary alert and alert B is the secondary alert. If alert C becomes a secondary alert for alert B, the application flattens the hierarchy so that A remains the primary and B and C become sibling secondary alerts, one level below A.

As another example, assume that there are three correlation rules that produce the following results:
  • Rule 1 (with an Order value of 1): B becomes a primary alert for A.
  • Rule 2 (with an Order value of 2): A becomes a primary alert for C and D.
  • Rule 3 (with an Order value of 3): E becomes a primary alert for A.

When alerts B, C, D, and E are triggered, they all appear in the console separately because there are no correlations between them.

When alert A is triggered:
  1. Rule 1 makes A a secondary alert under alert B.
  2. Rule 2 makes both C and D secondary alerts under alert A.
  3. Rule 3 makes A a secondary alert under E, giving alert A two primary alerts above it in the hierarchy.

Therefore, if all alerts are triggered, only B and E appear in the alert console indicated as primary alerts.

Note: A secondary alert can be correlated with more than one primary alert, and vice versa.