Rule-based alert grouping
Summarize
Summary of Rule-based alert grouping
Rule-based alert grouping in ServiceNow’s Event Management lets you organize related alerts by designating one as the primary (root cause) alert and others as secondary (related) alerts. This grouping is controlled by alert correlation rules that classify alerts based on defined filter conditions. The feature runs only on new alerts or alerts reopening from closed or flapping states. It helps reduce alert noise by focusing attention on the primary alerts while keeping secondary alerts grouped accordingly.
Show less
Key Features
- Primary and Secondary Alerts: Primary alerts represent the root issue, while secondary alerts relate to the same problem and are grouped under the primary alert.
- Alert Correlation Rules: These rules define filter conditions applied to alerts to determine their classification as primary or secondary.
- Alert Visibility and Closure Behavior: Both primary and secondary alerts remain visible. A system property controls whether secondary alerts close or remain open when the primary alert closes:
- If set to close, secondary alerts become standalone and closed after the primary alert closes.
- If set to remain open, secondary alerts become standalone but stay open after primary alert closure.
- Alert Hierarchy Limitation: Only one level of secondary alerts is supported. If a secondary alert has its own secondary alert, the hierarchy flattens to maintain two levels, grouping all secondary alerts directly under the primary alert.
- Express List View: Rule-based alert grouping is visible in the Express List of the Service Operations Workspace (ITOM), allowing you to easily see grouped alerts and their relationships.
Practical Application
By creating alert correlation rules, you can manually define which alerts act as primary (root cause) and which as secondary, enabling automated grouping of related alerts. For example, if a server goes offline (primary alert), alerts about virtual machines or applications on that server can be grouped as secondary alerts. This grouping helps you quickly identify the root cause and reduces alert noise by suppressing unnecessary secondary alerts, improving operational efficiency.
Alert Hierarchy Example
The hierarchy ensures that one alert cannot have multiple primary parents. When multiple correlation rules apply, the system enforces a single primary alert relationship and flattens any secondary alert levels beyond one. This behavior ensures clarity and prevents complex nested alert structures.
Rule-based alert grouping is created by alert correlation rules. These rules allow you to manually classify alerts as primary or secondary and establish a relationship between them. Use alert correlation rules to group related alerts. The rule runs only for new alerts or alerts whose status changed from close/flapping to open/reopen.
Example: If rule-based alert grouping is applied, secondary alerts indicating that virtual machines or applications on the offline server are also down and are grouped under the primary alert, which is the root alert for the server that is offline. You can view rule-based alert grouping in Express List of Service Operations Workspace (ITOM). For more information, see Viewing links between alerts in rules-based alert groups.
Primary and secondary alerts
- Primary alert: Identifies the root cause of an alert group and represents its secondary alerts.
- Secondary alert: Related to the same issue, they are grouped under the primary alert. The purpose of secondary alerts is to determine which alerts to suppress, reducing alert noise and allowing you to focus on the primary alert.
How primary and secondary alerts interact
In rule-based alert grouping, one of the real alerts is designated as the primary alert. Primary and secondary alert filter conditions specify which alerts are classified as primary and which as secondary. The filter criteria are applied to the Alert [em_alert] table.
In this alert grouping, both primary and secondary alerts are visible but secondary alerts are grouped under the primary alert. The property Keep the secondary alert open even when primary closed. for manual or rule based (evt_mgmt.rule_based_manual_closure) controls whether secondary alerts remain open or are closed when the primary alert is closed.
If the property is not selected (i.e., set to No), after the primary alert is closed, the parent reference is removed from the secondary alerts (the grouping is dissolved), and the secondary alerts are closed and become stand-alone. If you select the checkbox for the property (i.e., set it to Yes) and the primary alert is closed, the parent reference is removed from the secondary alerts (the grouping is dissolved), causing them to become stand-alone open alerts.
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.
- 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.
- Rule 1 makes A a secondary alert under alert B.
- Rule 2 makes both C and D secondary alerts under alert A, and the hierarchy is flattened so that A, C, and D become secondary alerts to the primary alert B.
- Rule 3 is not applied because multiple parents are not allowed—A already has B as its primary.
Therefore, if all alerts are triggered, only B appears as the primary alert for A, D, and C, while E remains a standalone alert.