Owners Manual

Understanding Event Life Cycle | Alarms, Events, and Automation
354 OMNM 6.5.2 User Guide
2 OpenManage Network
Manager internal trap
occurred
An internal trap occurred within OpenManage Network Manager. Many
situations are considered internal traps that emit an Event. One example is
when a monitor polls a certain target and retrieves data for an attribute
making the attribute cross a severity threshold. This emits a
monitorAttributeTrend Event.
3
Syslog message
received
The server received a Syslog message.
4
New Event
(Notification) created
OpenManage Network Manager creates a new Event (“Notification”) from
the data received. Such Events are specific to OpenManage Network
Manager’s internal processing.
5 Satisfies filter
conditions?
Syslog Event Processing Rules (EPRs) handle received Syslog messages to
determine whether to convert the message into a OpenManage Network
Manager Event or discarded. Such EPRs also determine how the Syslog data
creates the new Event (what severity, message, and so on, it has).
6
Reject If the received Syslog message does not satisfy the filter conditions of the
Syslog EPRs then it is rejected and no Event occurs.
7
Critical mining of
variable bindings
Sometimes OpenManage Network Manager must return to the device that
sent the original trap to “mine” additional variable bindings. This mining can
be either critical or latent, depending on whether OpenManage Network
Manager needs the additional information early in the Event life cycle or
whether it can wait until after an Alarm has been created.
If OpenManage Network Manager needs additional data to associate an Event
to an entity (which happens in #8. Entity lookup) then this is critical. On the
other hand if OpenManage Network Manager only needs this additional data
for an Alarm message, then this would be better configured as latent mining
of variable bindings of the Alarm. Critical mining is configured using the
Variable Binding Definition Editor on page 348
.
8 Entity lookup By default, OpenManage Network Manager associates Events with the IP
address of the device from which the original trap (or other kind of message)
came. The entity lookup process associates the Event to a subcomponent or
other type of entity if necessary based on the available variable bindings.
Sometimes OpenManage Network Manager must configure Event definitions
to associate Events based on them to the appropriate entities. You can
configure these through the
<EntityLookup> tag within
eventdefs.xml files. See Entity Lookup on page 337 for details.
9
Resolve Notification
Type OID from BED or
EED
The notification type OID is set on the Event either from the matching base
event definition (BED) or if there is an extended event definition (EED)
whose extension bindings match those in the Event then this notification type
OID is used instead. All default properties (such as severity, behavior, etc.)
and EPRs associated with the resolved Event Definition are used, whether this
happens to be a BED or EED.
10
Normalize device-
specific data for
standardized Event
processing
If the Event came from a device-specific trap then an Event Processing Rule
of type Device Access may exist that can normalize the payload. This then
facilitates standardized Event processing.
For example, OpenManage Network Manager can convert an Event based on
a Cisco-specific definition reporting on a failed login to a generic Event that
still reports on the failed login, but is not Cisco-specific. OpenManage
Network Manager applies any EPRs whose filter conditions match the
incoming Event here.
Process Description