Event Configuration

When setting event severities, it’s important to consider each event in the context of your infrastructure as a whole. Events whose severity is critical at the zoomed-in level of a single device may not merit a Critical severity in the zoomed-out view of your entire enterprise. Since an event with Critical severity can never have its alarms escalated, this severity level should usually be reserved for events that unequivocally indicate a truly critical impact to the business. Rock legend Nigel Tufnel offered some wisdom on the subject.

You can include various tokens in the description, log message, operator instruction, and automatic actions for each event. These tokens will be replaced by values from the current event when the text for the event is constructed. Not all events will have values for all tokens, and some refer specifically to information available only in events derived from SNMP traps.

Note that parameter descriptions use the percentage sign (%) as a delimiter to mark a replacement variable. If a literal % sign appears in your description, you must escape it with a %. For example:

'testUrl https://www.opennms.org/ReportSection?filter=FOO_BAR_BAZ%%20eq%%20%%27101%%27'

A node may have additional asset records stored for it. You can access these records using the asset replacement token, which takes the form:

A node may have additional hardware details stored for it. You can access these details using the hardware replacement token, which takes the form:

Many events carry additional information in parameters (see Anatomy of an Event). These parameters may start life as SNMP trap variable bindings, or varbinds for short. You can access event parameters using the parm replacement token, which takes several forms:

The ordering of event definitions is very important, as an incoming event is matched against them in order. It is possible and often useful to have several event definitions which could match variant forms of a given event, for example based on the values of SNMP trap variable bindings.

The tributary files included via the <event-file> tag have been broken up by vendor. When Meridian starts, each tributary file is loaded in order. The ordering of events inside each tributary file is also preserved.

The tributary files listed at the end of eventconf.xml contain catch-all event definitions. When slotting your own event definitions, take care not to place them below these catch-all files; otherwise your definitions will be effectively unreachable.

When debugging events, it may be helpful to lower the minimum severity at which Eventd will log from the default level of WARN. To change this setting, edit ${OPENNMS_HOME}/etc/log4j2.xml and locate the following line:

Changes to log42.xml will take effect within 60 seconds with no extra action needed. At level DEBUG, Eventd will log a verbose description of every event it handles to ${OPENNMS_HOME}/logs/eventd.log. On busy systems, this setting may create so much noise as to be impractical. In these cases, you can get terse event summaries by setting Eventd to log at level INFO and setting logEventSummaries="yes" in ${OPENNMS_HOME}/etc/eventd-configuration.xml. Note that changes to eventd-configuration.xml require a full restart of Meridian.

Use the opennms:show-event-config command to render the event definition for one or more event UEIs (matching a substring) to XML. This command is useful for displaying event definitions that may not be easily accessible on disk, or verifying that particular events were actually loaded.