Users Guide

Event Definitions | Alarms, Events, and Automation
OMNM 6.5.3 User Guide 335
Default Behavior
—The options for behavior ( Undefined, Alarm, Suppress, Reject ). Alarm means:
Process at the mediation server, generate event history and an alarm.
Suppress means: Process
at the mediation server and generate an event (
not an alarm). Reject means: Reject at the
mediation server (do not process)
Resource Propagation —The hierarchical resource propagation behavior for any alarm based on
this event definition (either
Default, Impacts subcomponents, or Impacts top level, or Impacts
Top Level and Subcomponents
). (See also Understanding Alarm Propagation to Services and
Customers
on page 350 for more about how this impacts services and customers.)
An event definition configures “Resource Propagation” (distinct from “Alarm propagation”)
based on the event type. Do alarms based on this event definition impact the overall device
(
Impacts top level ), subcomponents ( Impacts subcomponents ), both (Impacts Top Level and
Subcomponents) or just the correlated inventory entity (
Default )?
Alarm behavior differs for monitorAttributeTrend alarms when an SNMP Interface monitor
targets a Port/Interface rather than targeting a device. If the alarm comes from the former, and
its correlation state is not
Top L evel Alarm , only the port appears alarmed, not the device. If
the monitor target is the device, however, the device appears as alarmed. If the monitor has
Port targets, then you must configure propagation to
Top L evel Alarm to see the device
alarmed in, for example, the System Topology view.
Service Affecting —Check this if the event has an impact on services. Indicates whether the alarm
has an impact on services. If this is checked then alarms based on this event definition
propagate calculated alarm states across services and customers that depend on the (directly)
alarmed resource.
For example: If a resource has a service affecting alarm, then OpenManage Network Manager
propagates the severity of this alarm across all associated services and customers. If the
resource alarm is “clear” then all services depending on this resource are “clear” too. If the
resource alarm is “critical,” then all services depending on that resource are “critical” too.
NOTE:
Alarms imported from previous versions appear as not service affecting, regardless of severity.
For more about propagation, see Understanding Alarm Propagation to Services and
Customers
on page 350.
Service Propagation — This only affects alarm propagation if Service Affecting is true for the event
definition. This is like Resource Propagation, but controls only whether alarms affect services
associated with entities hierarchically related to the alarmed entity. For example, if a port
alarm is created and its event definition specifies that the Service Propagation is Impacts
Subcomponents then the alarm propagates only to the services associated with this port's
interfaces. This does not affect the services associated with the top-level device.
Advisory Text —The Advisory Text appears with the event. Configure it in the text box here.