Events are central to the operation of the OpenNMS HORIZON platform, so it’s critical to have a firm grasp of this topic.
|Whenever something in OpenNMS HORIZON appears to work by magic, it’s probably events working behind the curtain.|
Events are structured historical records of things that happen in OpenNMS HORIZON and the nodes, interfaces, and services it manages. Every event has a number of fixed fields and zero or more parameters.
A string uniquely identifying the event’s type.
UEIs are typically formatted in the style of a URI, but the only requirement is that they start with the string
A short, static label summarizing the gist of all instances of this event.
A long-form description describing all instances of this event.
A long-form log message describing this event, optionally including expansions of fields and parameters so that the value is tailored to the event at hand.
A severity for this event type.
Possible values range from
A numeric identifier used to look up a specific event in the OpenNMS HORIZON system.
A set of instructions for an operator to respond appropriately to an event of this type.
If this field is provided for an event, OpenNMS HORIZON will create, update, or clear alarms for events of that type according to the alarm-data specifics. For more about alarms and how they relate to events, see [alarms-introduction].
Events may originate within OpenNMS HORIZON itself or from outside.
Internally-generated events can be the result of the platform’s monitoring and management functions (e.g. a monitored node becoming totally unavailable results in an event with the UEI
uei.opennms.org/nodes/nodeDown) or they may act as inputs or outputs of housekeeping processes.
The following subsections summarize the mechanisms by which externally-created events can arrive.
If SNMP-capable devices in the network are configured to send traps to OpenNMS HORIZON, these traps are transformed into events according to pre-configured rules. The
Trapd service daemon, which enables OpenNMS HORIZON to receive SNMP traps, is enabled by default.
Event definitions are included with OpenNMS HORIZON for traps from many vendors' equipment.
Syslog messages sent over the network to OpenNMS HORIZON can be transformed into events according to pre-configured rules.
Autonomous messages can be retrieved from certain TL1-enabled equipment and transformed into events.
Any application or script can create custom events in OpenNMS HORIZON by sending properly-formatted XML data over a TCP socket.
At the heart of OpenNMS HORIZON lies an event bus. Any OpenNMS HORIZON component can publish events to the bus, and any component can subscribe to receive events of interest that have been published on the bus. This publish-subscribe model enables components to use events as a mechanism to send messages to each other. For example, the provisioning subsystem of OpenNMS HORIZON publishes a node-added event whenever a new node is added to the system. Other subsystems with an interest in new nodes subscribe to the node-added event and automatically receive these events, so they know to start monitoring and managing the new node if their configuration dictates. The publisher and subscriber components do not need to have any knowledge of each other, allowing for a clean division of labor and lessening the programming burden to add entirely new OpenNMS HORIZON subsystems or modify the behavior of existing ones.