Owners Manual

Understanding Alarm Life Cycle | Alarms, Events, and Automation
OMNM 6.5.2 User Guide 357
The following items correspond to the numbered processes in the diagram.
Process Description
1
Alarm correlation An Event occurred and was not marked as Reject.
2
Marked as suppress? Is the behavior of the Event Suppress? At this point, this might occur because
of the default behavior of the Event Definition or possibly because of an
override mapping event processing rules (EPR).
3
Event is persisted but
creates no Alarm
If OpenManage Network Manager suppresses the Event then it is inserted to
the database but the insertion creates no Alarm
4
Source entity under
Alarm suppression?
Is the entity that is the source of the Event under Alarm suppression? This
can be scheduled or indefinite.
5
Severity is already set
to cleared
Is the severity of the Event set to Cleared?
6
Clear open correlated
Alarms
Clear all open Alarms correlated to this Event. Correlated implies more than
one meaning for Alarms and/or Events: this correlation refers to rising/clearing
correlation. How the Event Definitions associated with these Alarms/Events
are correlated to each other is what drives this.
7
Latent mining of
variable bindings
OpenManage Network Manager must sometimes return to the device that
sent the original trap to “mine” additional variable bindings. Such mining can
be either critical or latent, depending on whether this additional information
is needed early in the Event life cycle or whether it can wait until after
OpenManage Network Manager creates an Alarm.
If OpenManage Network Manager needs additional data to associate an Event
to an entity (which happens in # 8. Entity lookup in the Understanding Event
Life Cycle diagram) then mining is critical, as described below. Critical
mining of variable bindings also within the Event Life cycle diagram. On the
other hand if this additional data is only needed for an alarm message, then it
this would be better configured as latent. See Variable Binding Definition
Editor on page 348.
8
Opened correlated
Alarms exist?
Are there any open Alarms that correlate to this Event? Here, “correlated”
refers to the correlation of a single open Alarm to one or more Events. The
first of these was the Event that made the Alarm open. If the original Alarm is
still open, each subsequent correlated Event does not open a new Alarm,
instead incrementing this Alarm’s count. Events correlate to existing open
Alarms provided it meets all of the following conditions: 1) It is based on the
same Event Definition as the Alarm 2) It has the same values for all key
bindings as the Alarm 3) It is associated with the same entity as the Alarm.
9
Correlated Alarm has
the same severity and
message?
Are the severity and the message associated with this new Event the same as
those of the correlated Alarm?
10 Escalate/de-escalate to
new severity and
message
Escalate or de-escalate the correlated Alarm by editing its severity and
message to match that of the new Event.
11 Increment Alarm
count
Increment the count of the correlated Alarm.
12
Clear extra correlated
Alarms
Only one open correlated Alarm can exist. It is unusual, although not
impossible, for more than one open Alarm to correlate to each other. If this
happens it would probably be due to concurrency issues across multiple
application servers. If this does happen then one of the Alarms can stay open
and OpenManage Network Manager clears the others.