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.

Anatomy of an Event

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.

Mandatory Fields
UEI (Universal Event Identifier)

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 uei..

Event Label

A short, static label summarizing the gist of all instances of this event.

Description

A long-form description describing all instances of this event.

Log Message

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.

Severity

A severity for this event type. Possible values range from Cleared to Critical.

Event ID

A numeric identifier used to look up a specific event in the OpenNMS HORIZON system.

Notable Optional Fields
Operator Instruction

A set of instructions for an operator to respond appropriately to an event of this type.

Alarm Data

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].

Sources of Events

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.

SNMP Traps

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.

Disabling the Trapd service daemon will render OpenNMS HORIZON incapable of receiving SNMP traps.

Event definitions are included with OpenNMS HORIZON for traps from many vendors' equipment.

Syslog Messages

Syslog messages sent over the network to OpenNMS HORIZON can be transformed into events according to pre-configured rules.

The Syslogd service daemon, which enables OpenNMS HORIZON to receive syslog messages over the network, must be enabled for this functionality to work. This service daemon is disabled by default.

TL1 Autonomous Messages

Autonomous messages can be retrieved from certain TL1-enabled equipment and transformed into events.

The Tl1d service daemon, which enables OpenNMS HORIZON to receive TL1 autonomous messages, must be enabled for this functionality to work. This service daemon is disabled by default.

XML-TCP

Any application or script can create custom events in OpenNMS HORIZON by sending properly-formatted XML data over a TCP socket.

ReST

Posting an event in XML format to the appropriate endpoint in the OpenNMS HORIZON ReST API will cause the creation of a corresponding event, just as with the XML-TCP interface.

The Event Bus

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.