Alert Lifecycle

An alert is a complex object with a multi-stage lifecycle. This section provides an overview of available alert states and their transitions, while subsequent articles describe the details.

Each alert can have multiple triggers (of variable and/or event type), and each trigger has a Context Mask defining the context or group of contexts which are its alert sources. Internally, an instance of each trigger is created to monitor each context matching the mask. For example, if an alert has two triggers, the first of them having 10 contexts matching its mask, and the second one having 20 contexts, the alert will have a total of 30 trigger instances.

Each trigger instance performs the monitoring of its "peer" context in its own way, separately from the others. Variable triggers periodically evaluate a trigger Expression against its peer context's values, while event triggers simply wait for occurrences of the Event.

At a certain moment, a trigger may decide that the trigger condition is satisfied. This process is called "alert raising" which starts the following actions:

• An Alert Event instance is created, saved to the appropriate database and sent to subscribed listeners.

• Alert notifications are sent as e-mails and/or SMS messages.

• An alert popup is shown to system operators.

• If the Acknowledgement Required option is set, the operators are prompted to acknowledge the alert. Acknowledging an alert is technically acknowledging a corresponding Alert event instance. This alert event can be later acknowledged by any other means, such as from the Event Log's context menu.

• Corrective actions (both automatic and interactive) are executed.

• If system operators have an open Event Log those filter is set up to monitor Alert events (e.g. Alerts or similar filter is active), the operators will also see the Alert event in Event Log.

• If the setting Activate alert when there are pending (non-acknowledged) instances is enabled for the alert, the alert will change its state from Normal to Active.

• If the setting Number-based escalation is enabled and the number of pending (non-acknowledged) Alert event instances exceeds the Number of pending alerts required to initiate escalation threshold, the alert will switch from Active to Escalated state. The escalation notifications (e-mail and SMS) are also sent in this case.

• The trigger itself may activate. For variable triggers, activation will happen in any case. For event triggers, the activation will happen only if the trigger has a Correlated event set and, thus, the system knows how to deactivate it upon a "paired" event.

• If the trigger was activated, the alert will switch from Normal to Active state.

• The activated trigger will be added to alert's Active Instances list.

• The activated trigger will also be added to the Active Alerts list of the alert source context (the one those event/state has raised the alert).

If the Time-based escalation setting is enabled, the alert tracks the time elapsed since each of those instances was raised. If this time exceeds the value of the Time before escalation threshold, the alert is escalated and changes its state from Active to Escalated. The escalation notifications (e-mail and SMS) are also sent in this case.

Every active trigger instance continues monitoring in its own way. A variable trigger will be deactivated after a delay since the result of the Expression will switch to FALSE or the Deactivator expression will switch to True. An event trigger will be deactivated if Correlated event(s) are received.

Once any trigger is deactivated, the following happens:

• The deactivated trigger will be removed from the Active Instances list of the alert.

• The deactivated trigger will be removed from the Active Alerts list of the alert source context (the context whose event/state raised the alert).

• If no other triggers are active and there are no pending instances, the alert state will change its state back from Active to Normal.

Alerts caused by Event Triggers remain active until a Correlated event occurs (if it's specified in the trigger settings). However, in some cases, this event may never occur, e.g., because it was lost due to a network failure or not produced due to an originating device problem.

For such cases, it's possible to deactivate a trigger manually. To do that, find an alert instance in the Active Instances table, right-click on it, and select Deactivate Alert. The trigger will be deactivated without waiting for a correlated event.

If any Alert event was acknowledged and the Activate alert when there are pending (non-acknowledged) instances setting is enabled for the alert, any of the following can occur:

• If the alert was Escalated, but there are no non-acknowledged instances that have been pending for longer than Time before escalation, and the number of pending instances is below the Number of pending alerts required to initiate escalation, the alert will be de-escalated and change its state from Escalated to Active.

• If there are no other pending (non-acknowledged) alert instances, the alert will change its state back from Active to Normal.

Was this page helpful?

Tell us more

Send

Thank you!