Owners Manual

Understanding Event Life Cycle | Alarms, Events, and Automation
OMNM 6.5.2 User Guide 355
11 Apply Event Definition
override mappings
By default, the Event Definition determines the data attributes of an Event,
but some Event Processing Rules can override these defaults. Such EPRs can
override attributes like severity, service affecting, and behavior. OpenManage
Network Manager applies any such enabled EPRs whose filter conditions
match the incoming Event here.
12
Apply stream base
correlation
OpenManage Network Manager considers frequent Events a stream that
might correlate within the steam base. Users can control stream base
correlation by creating Event Processing Rules to detect patterns in the
frequency of incoming Events for the purpose of minimizing the number of
Events submitted to the application server for further processing. This
includes EPRs of type State Flutter and Frequency Threshold. OpenManage
Network Manager applies any such enabled EPRs whose filter conditions
matches the incoming Event here. If an Event matches a steam base
correlator then this step might be the end of its processing.
13
Marked for reject? Is the behavior of the Event “Reject”? If so, then OpenManage Network
Manager does insert it into the database. In most cases rejected Events do not
go to the application server for further processing if, but some Events require a
trigger for correct system behavior and therefore must be processed by the
system even when rejected. OpenManage Network Manager posts such
Events to the application server for further processing but does not insert
them into the database.
14
Reject OpenManage Network Manager rejects the Event rather than inserting it into
the database. Note that even rejected Events might have some effect, like
triggering device driver processing, despite not being persisted to the
database. See # 13. Marked for reject?
15
Post Events to
application server
In distributed environments, much of this processing is going on within the
mediation server. Events that make it through to this point are posted to the
application server so that they can be inserted into the database and for
additional processing to take place that depends on data that needs to be
queried from the database, including Alarm Correlation.
16 Receive Events Application server receives Events from the mediation server.
17 Execute device driver
processing
Some managed devices have drivers that feature follow-up Event processing.
If the Event originated from a such a device then this step executes that
follow-up processing.
18 Perform Alarm
Correlation
Go to step one of the Understanding Alarm Life Cycle diagram. This process
might create, edit, or clear an Alarm.
19
Persist Event to DB Saves the Event to the database for future reference.
20
Execute automation
actions
If any automation Event Processing Rules satisfy the filter conditions of the
Event, then the OpenManage Network Manager application executes the
associated actions here. Actions may include sending an email, forwarding the
Event northbound as an SNMP trap, signifying that the configuration was
changed on the device, and so on.
21
Done Processing on the application server is done for this Event.
22
Apply Database Aging
Policy
This begins the process that applies Database Aging Policies (DAP) to delete
old Events.
23
Delete old Events Delete the old Events according to the active DAP for Events.
24
Done Done applying database aging policies for Events.
Process Description