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 (resolved). 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 priority/secondary score used for ranking.

Alert severity and priority

Event Management normalizes vendor severities into a standard scale. Severity 0 = Clear, and higher numbers escalate through Info, Warning, Minor, Major, to Critical (the highest actionable). Operators triage by severity, but the system also computes a priority/secondary alert score that blends severity with business impact (for example, how many services or how critical a service the CI supports). Service-aware scoring is what lets an operator focus on the alert that actually threatens a revenue-bearing 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.
• Service Analytics / machine-learning correlation — Operational Intelligence learns patterns and groups alerts that frequently occur together, producing correlated alert groups even when alerts are not identical.

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 Service Analytics correlated 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 are automation that fires when an alert matches a condition. They can:

• Resolve/close alerts automatically (for example, auto-close low-severity alerts after a window, or close on receipt of a clear event).
• Group or transform alerts.
• Trigger remediation — invoke a remediation subflow or create a task.
• Create tasks/incidents — open an incident (or other task) for alerts that meet a threshold of severity or impact.

These rules also run in order and have conditions, 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) that perform common fixes — restart a service, clear a queue, run a diagnostic. 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 configuration (often an alert management rule or a dedicated setting) that decides which alerts warrant a task, how the task is populated (CI, short description, severity-to-priority mapping), and how the alert and the resulting incident stay linked so that closing one can reflect on the other. 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.

---