Users Guide

Understanding Alarm Life Cycle | Alarms, Events, and Automation
358 OMNM 6.5.3 User Guide
13 Open new Alarm and
persist to DB
Open a new Alarm and persist it to the database so that it can be queried later.
14 Perform automatic
parent/child
correlation
If your configuration designates open Alarms the parent or child of a new
Alarm then OpenManage Network Manager automatically creates the parent/
child relationship. This derives from configurations made within the Event
Definitions that are the basis of the Alarms. You configure this through the
CorrelatedParentData tag of the eventdefs.xml files.
15 Alarm Propagation This is the start of process propagating Alarm States to associated entities.
16 Propagate up and/or
down the resource
hierarchy
Depending on the Alarm’s resource propagation attribute, it might propagate
Alarm States to the subcomponents of the alarmed entity and/or to the top
level device.
17 Propagate to associated
Links
Propagate the Alarm States to the Links associated with the source entity.
OpenManage Network Manager compares the severity of the A and Z
endpoints and sets the severity of the Link to the higher of the two.
18 Service affecting? Is this Alarm service affecting? This will either come from the default
behavior of the Event Definition or else a mapping Event Processing Rule
(EPR) may override it.
19 Propagate Alarm State
to deployed Services
and Customers
Propagate the Alarm State to the deployed Services and Customers associated
with the source entity. This uses the severity calculator configured for the
association type being used to route the propagation. This occurs one
association route at a time, where if one routing and calculation results in a
change in severity of the target entity then it will find the targets associated
with that entity and route to them to do another round of calculation. This
propagation is recursive and only stops once there are no more target entities
whose severity has changed as a result of the calculation.
20 Done Processing on the application server is done for this Alarm.
21 Clear Alarm request The user manually clears an Alarm.
22 Persist clear to the
database
The database is updated to make this Alarm cleared.
23 Execute Propagation Go to # 15. Propagate Alarm States to the associated entities.
24 Alarm has children? Does the Alarm have children? This includes other Alarms that are caused by
or blocked by this one.
25 Clear child Alarms Clear all of this Alarm’s children.
26 Un-parent child
Alarms
Update all of this Alarm’s children so that they are top-level Alarms (no longer
children of any other Alarm).
27 Children are caused by
parents?
Are the child Alarms caused by the parent? This comes from the correlation
state of the child Alarms. There is more than one sense of what it means for
Alarms and/or Events to be “correlated” so to clarify in this context the
“correlation state” refers to Alarm parent/child correlation.
28 Done Processing on the application server is done for this Alarm.
29 Apply Database Aging
Policy
This is the start of the process that applies Database Aging Policies (DAP) to
delete old Alarms.
30 Delete old Alarms Delete the old Alarms according to the active DAPs for Alarms. Note that
there can be more than one active DAP, which might include one to delete old
cleared Alarms and possibly another to delete very old Alarms that are still
open, if this is desired.
31 Done Done applying database aging policies for Alarms.
Process Description