Event Daemon Configuration

Core Meridian events are pre-loaded in the database and are essential for system operation. These events handle internal Meridian functionality such as node discovery, service monitoring, and alarm management.

Vendor-specific event definitions for third-party devices are available in ${OPENNMS_HOME}/etc/examples/events/. This directory contains pristine, unmodified event configuration files for hundreds of vendors including:

These files are provided as examples and can be uploaded to Meridian as needed for your environment. You only need to upload the event files relevant to the devices in your network.

During the upgrade to the database-backed event configuration, your existing event files from ${OPENNMS_HOME}/etc/events/ are moved to ${OPENNMS_HOME}/etc_archive/events/ and are not automatically imported into the database.

If you have customized vendor event files (for example, with adjusted severities, custom UEIs, or local additions), upload those files from ${OPENNMS_HOME}/etc_archive/events/ into the database through the UI or the POST /api/v2/eventconf/upload REST endpoint to preserve your customizations.

If you did not modify the vendor event files, you can upload the pristine versions from ${OPENNMS_HOME}/etc/examples/events/ instead.

Event definitions are organized into sources. Each source typically corresponds to a single event configuration file and contains one or more event definitions. Sources have the following properties:

When setting event severities, it is 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, you should usually reserve this highest severity level for events that unequivocally indicate a truly critical impact to the business. Rock legend Nigel Tufnel offered some wisdom on the subject.

An incoming event is matched against the event definitions in evaluation order, and the first matching definition wins. It is possible, and often useful, to have several event definitions that could match variant forms of a given event; for example, based on the values of SNMP trap variable bindings.

The order has two levels, both stored in the database and shown as the Order columns in the UI:

Both levels can be rearranged after upload:

A file named eventconf.xml in the upload is not stored as a source: its <event-file> entries define the evaluation order of the sources, first entry evaluated first. Sources it does not list are evaluated before the listed ones, and the catch-all source always stays last. This also works as an upload of its own, to apply an order to the sources already in the database — for example to carry over the order of a pre-upgrade eventconf.xml. The upload report states when a source order was applied.

Uploading a file whose name matches an existing source replaces that source and all of its events — this is the supported way to update a source from a file. The UI flags such files first, so you can rename the file or confirm the replacement (per file, or with Replace all for a re-imported directory). When two files in one upload resolve to the same name, only the first is stored; the report names the files that were dropped.

Single events can also be changed without re-uploading the whole file: edit them in the UI, or use PUT /api/v2/eventconf/sources/{sourceId}/events to update one event identified by its exact UEI and mask (or append it when no match exists).

The Meridian web interface provides a comprehensive event configuration management interface where you can:

The Event Configuration REST API (/api/v2/eventconf) provides programmatic access to all event management functions. API documentation is available via Swagger UI at http://<opennms-host>:8980/opennms/ui/index.html#/open-api.

Key operations include:

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.