Home Orlando IT Operations Management IT Operations Management ITOM Health Event Management Manage and monitor alerts Alert correlation rules

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 list in Alert Intelligence.

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. You can see these groups in the alert list in Alert Intelligence.

When working with alerts:

Secondary alerts remain open after a primary alert is closed in rule-based groups when the evt_mgmt.rule_based_manual_closure property is set to true.
The history of a secondary alert is retained after a primary alert is closed.
The alert management job runs even if the alert grouping job is not complete, if a specified time frame has passed. When this occurs, you can enable the Avoid INTs on secondary alerts rule to prevent incidents from being created for secondary alerts (when the evt_mgmt.avoid_int_enabled property is enabled), since an incident already exists for the primary alert.
By default, the Alert Group and Alert Management jobs run independently of each other. To avoid creating an incident on a secondary alert, set evt_mgmt.avoid_int_enabled = true, ensuring that the Alert Management job is executed after the Alert Group job is completed. Additionally, you must configure the Alert Management rule for Incident creation to filter out secondary alerts.
Note: If the primary alert was not created when the Alert Management job started, an incident is created even if the alert becomes secondary during the next Alert Grouping job execution.

How primary and secondary alert management rules work

Primary and secondary alert management 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 alert list separately because there are no correlations between them.

When alert A is triggered:

Rule 1 makes A a secondary alert under alert B.
Rule 2 makes both C and D secondary alerts under alert A.
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 list, indicated as primary alerts.

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

Previous topic

Next topic

Release version

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.

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.

When working with alerts:

Secondary alerts remain open after a primary alert is closed in rule-based groups when the evt_mgmt.rule_based_manual_closure property is set to true.
The history of a secondary alert is retained after a primary alert is closed.
The alert management job runs even if the alert grouping job is not complete, if a specified time frame has passed. When this occurs, you can enable the Avoid INTs on secondary alerts rule to prevent incidents from being created for secondary alerts (when the evt_mgmt.avoid_int_enabled property is enabled), since an incident already exists for the primary alert.
By default, the Alert Group and Alert Management jobs run independently of each other. To avoid creating an incident on a secondary alert, set evt_mgmt.avoid_int_enabled = true, ensuring that the Alert Management job is executed after the Alert Group job is completed. Additionally, you must configure the Alert Management rule for Incident creation to filter out secondary alerts.
Note: If the primary alert was not created when the Alert Management job started, an incident is created even if the alert becomes secondary during the next Alert Grouping job execution.

How primary and secondary alert management rules work

Alert relationships

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

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 alert list separately because there are no correlations between them.

When alert A is triggered:

Rule 1 makes A a secondary alert under alert B.
Rule 2 makes both C and D secondary alerts under alert A.
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 list, indicated as primary alerts.

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

How search works:

Topics are ranked in search results by how closely they match your search terms

Alert correlation rules

Alert correlation rules

Primary and secondary alerts

How primary and secondary alert management rules work

Alert relationships

When correlation rules run

Alert hierarchy

On this page

Alert correlation rules

Alert correlation rules

Primary and secondary alerts

How primary and secondary alert management rules work

Alert relationships

When correlation rules run

Alert hierarchy

Log in to personalize your search results and subscribe to topics