Users Guide

Event Definitions | Alarms, Events, and Automation
OMNM 6.5.3 User Guide 333
Share with User— Opens the Share with User window where you select the colleague you want to
share this assets with and then type your message.
You can also configure an Aging Policy and View events as PDF in this menu. See
Implementing
DAP
on page 73 for more details.
To see an event’s propagation policy, you can view the editor panel described below. See also
Understanding Alarm Propagation to Services and Customers on page 350.
Unknown Traps
OpenManage Network Manager normalizes all incoming traps not elsewhere defined as
redcellUnknownTrap (essentially “none of the above”). When a trap arrives with an OID not
in the list of event definitions then the
redcellUnknownTrap determines its behavior. You can
configure OpenManage Network Manager to reject all such traps, suppress them so that they
become events or allow them all to become full-fledged alarms.
You can also create event processing rules to handle (suppress, alarm, send e-mail) any such events.
See
Creating Event Processing Rules on page 300. The redcellUnknownTrap ’s default
behavior is suppress, its default severity is indeterminate. Events and alarms that are unknown still
contain the notification OID from the trap. As a formality,
redcellUnknownTrap has its own
notification OID.
Different Forms of Event and Alarm Correlation
OpenManage Network Manager supports different forms of event and alarm correlation:
•
Stream Based Correlation: When multiple events occur within the mediation server and
there are rules that correlate them with each other so that when a certain kind of pattern is
detected (frequency threshold, state flutter), this affects which events the mediation server
submits to the application server. You can configure this form of correlation by creating
certain types of event processing rules. See
Stream Based Correlation on page 303
•
Event to Alarm correlation : Open alarms are uniquely identified by the source entity and the
key bindings. This means that if a new alarm comes in that is essentially identical to an
existing open alarm, this will increment the count of the open alarm and also in some cases
escalate it or de-escalate it (if the incoming alarm has a different severity level or a different
message). This is facilitated by the correlation hash field on each alarm record, which encodes
all of the fields relevant for correlation. Note that for key bindings, the data within the binding
that is used for correlation depends on how the variable binding definition is configured. If it
is configured to correlate By Value then the value within the binding is used and conversely if
it is configured to correlate By Index then the index of the OID is used. The index is the last
segment in the OID string after the defined OID. For example, if a variable binding definition
has an OID of 1.2.3 and the payload of a trap has a variable binding based on this definition
with an OID of 1.2.3.55 then 55 is the index of this binding. There will also be a value
associated with this binding in the payload of the trap, which is different from the index. See
Key Bindings within
Correlations on page 338 for more information.
•
Raising/Clearing Alarm Correlation : When an open alarm with a raising severity (Critical,
Major, Minor, or Warning) is correlated with another alarm that was recently created whose
severity is cleared, this will then clear the raising alarm (it will no longer be opened). See
Event Definitions Correlated Events for Raising/Clearing within
Correlations on page 338 for
more information.
•
Parent/Child Alarm Correlation: In some cases an alarm can cause other alarms to be created
and in other cases an alarm can block other alarms from being addressed. In these cases the
causing or blocking alarm becomes the parent and the alarms that were caused or blocked are
the children. This form of correlation can be performed manually or automatically. For