Alerts and Tasks

The second-heaviest domain. If Domain 3 is "how an alert is born," Domain 4 is "what happens to the alert for the rest of its life": correlation, aggregation, prioritization, remediation, task/incident creation, and closure.

The alert record and its lifecycle

An alert moves through states. The canonical ones are Open (active, needs attention), Reopen (was closed but a new matching event arrived), Flapping (oscillating), and Closed (no further action required). A key behavior: when the underlying condition clears, a resolution (clear) event can automatically close the alert, and a later recurrence can reopen it. Operators can also manually acknowledge, close, or assign alerts.

Important alert fields include severity (Critical, Major, Minor, Warning, Info / Clear), state, the bound CI, the source, the message key, event count, and the computed alert priority score used for ranking.

An alert closes manually, automatically when a closing event arrives on the same message key (Clear severity, or a resolution state of Closing), or when its related incident is resolved (property evt_mgmt.incident_closes_alert). Closing an alert also closes a related incident that is not already resolved or closed (property evt_mgmt.alert_closes_incident). There is no "Resolved" alert state.

Alert severity and priority

Event Management normalizes vendor severities into a standard numeric scale: 1 Critical, 2 Major, 3 Minor, 4 Warning, 5 Info (shown as OK on events), plus 0 Clear, which closes the matching alert. For active problems a lower number means higher urgency, so Critical (1) is the most urgent. An alert's severity is copied from each incoming event for its message key; when the event closes the alert, the previous severity is kept for reporting. Operators triage by severity, but the system also computes an alert priority score, a weighted composite led by the number of impacted services factored by their business criticality, then severity, CI type, alert role (primary, secondary or none), the number of secondary alerts, and state. The category order and weights are configurable. Service-aware scoring is what lets an operator focus on the alert that actually threatens a critical service rather than the loudest alert.

Alert correlation rules

Alert correlation reduces the number of alerts an operator must look at by establishing primary/secondary (parent/child) relationships between alerts that are part of the same underlying problem. The operator then works the primary alert; the secondaries are suppressed under it.

Correlation can be driven by:

• CMDB / topology-based correlation: alerts on CIs that are related in the CMDB (for example, a host and the application running on it) are grouped, often with the upstream/root CI's alert designated primary. For CIs without historical learning data, the system falls back to CMDB relationships.
• Alert correlation rules: explicitly authored rules that define which alerts correlate and which becomes primary.
• Automated alert grouping (machine learning): the Alert Aggregation Learner studies historical alerts and groups alerts that frequently occur together, producing automated alert groups even when alerts are not identical. It needs alert history, so groupings are weak right after go-live.

When a primary alert is closed, its secondary alerts are also closed by default; for manual and rule-based groups the property evt_mgmt.rule_based_manual_closure can keep them open instead.

Alert aggregation

Alert aggregation groups related alerts to support root-cause analysis. Where correlation produces primary/secondary pairs, aggregation forms broader alert groups (including CMDB alert groups and automated alert groups) that represent one underlying event or incident. The goal is the same throughout the domain: fewer things for a human to look at, with the likely root cause surfaced.

Alert management rules (resolving and acting on alerts)

Alert management rules (the Alert Rules Management application, sn_em_arm) are automation that fires when an updated, open alert matches the rule's filter; they do not run on closed alerts. They can:

• Run subflows, including base-system subflows such as Create Incident, Close Alert, Acknowledge Alert, and Change Alert to Maintenance Mode.
• Trigger remediation: launch a remediation subflow or workflow automatically, or let an operator run it manually.
• Create and link records: generate incidents, tasks, or knowledge articles for alerts that meet the filter.
• Launch applications or URLs built from alert field values.

Closing an alert on a clear event is native event processing, not an alert management rule. Legacy alert action rules from earlier releases must be migrated to alert management rules before they can be modified. Alert management rules are evaluated in ascending Order (default 100) by a scheduled job that runs every 11 seconds by default, so specificity and sequencing matter just as with event rules.

Remediation (subflows and Flow Designer)

Remediation is the bridge from detection to automated resolution. Event Management ships base-system subflows (built in Flow Designer) for common alert handling: Create Incident, Close Alert, Acknowledge Alert, Change Alert to Maintenance Mode, and major incident variants. Fixes such as restarting a service or gathering diagnostic data are built as custom subflows (or Orchestration workflows; subflows are recommended for performance). You configure alert remediation actions so an operator (or an automatic rule) can launch a remediation subflow directly from the alert.

Two modes to distinguish:

• Manual / on-demand remediation: the operator clicks a remediation action on the alert; the subflow runs and the outcome is recorded back on the alert.
• Automatic remediation: an alert management rule launches the subflow without human intervention when conditions are met.

You build custom remediation in Flow Designer as a subflow (so it can accept the alert as input and be reused) rather than as a one-off flow.

Tasks and incident creation

Event Management can create incidents (and other tasks) from alerts. This is governed by an alert management rule that runs the Create Incident subflow (or, in Service Operations Workspace, a Create incidents alert automation) and decides which alerts warrant a task and how the task is populated from alert fields. The Create Incident subflow does not run for alerts in maintenance or alerts that already have an incident. The alert and the resulting incident stay linked so that closing one can reflect on the other (properties evt_mgmt.alert_closes_incident and evt_mgmt.incident_closes_alert). The exam expects you to know that incident creation is configurable and conditional, not automatic for every alert.

Scheduled jobs

Several background scheduled jobs drive alert lifecycle behavior: processing events, evaluating correlation, closing stale alerts, and recomputing scores. Knowing that these are scheduled jobs (and that delays in alert behavior can trace back to job timing) is fair game.

---