OpenNMS Plugin API

OpenNMS provides a development ecosystem that helps integrate network monitoring data into a generalized framework of events, metrics, flows, and topology. The OpenNMS Plugin API (previously known as OIA) is a stable Java API that helps users add new functionality and integrations.

The OpenNMS Plugin API is a reliable resource to build plugins that exchange information between OpenNMS and other systems. The Plugin API clearly identifies, documents, and provides ongoing compatibility guarantees. Developers can create plugins that target a clear set of interfaces and work across future releases. As the Plugin API adoption increases, the community will benefit from an ecosystem of plugins that users can build more quickly, validate more easily, and rely on for ongoing compatibility.

Plugin API users can take advantage of the following features and interfaces. See the interfaces defined in the API module for a complete list.

Extend

  • Event configuration
  • Syslog configuration (message to event mappings)
  • SNMP data collection configuration
  • Resource type definitions (data collection)
  • Graph definitions (data collection)
  • Thresholding configuration

Consume

  • Runtime information
    • Version - major, minor, patch, snapshot
    • Container type - OpenNMS vs. Minion vs. Sentinel
  • Alarm lifecycle callbacks
  • DAOs
    • Node
    • SNMP interface
    • Topology (edges)
  • Coordination API
  • Events

Expose

  • Health checks

    • Provide custom health checks to verify your plugin
  • Alarm persister extensions
    • Enrich alarms before they are persisted
  • Service monitors
  • Service collectors
  • Provisiond detectors
  • Ticketers
  • Time Series Storage
  • Graph API extensions (i.e., custom topology)

Alarm Triage with ALEC

The Architecture for Learning Enabled Correlation (ALEC) framework uses artificial intelligence and machine learning to group related alarms to better manage the more complex situations they might represent.

ALEC uses temporal clustering techniques, machine learning algorithms, and deep-learning technology with topology data to group related alarms into a high-level situation. ALEC can’t identify the cause of the problem, but it can indicate that alarms that happened at the same time on the same node might be related.

Note: ALEC is a community plugin. As such, it's available to all users and customers, but does not qualify for SLA-backed support unless specific arrangements for an exception are in place with OpenNMS Support.

Additional OpenNMS Plugins

The following experimental plugins are best for use in a non-production environment.

Developers who want to experiment:

  • ACI: Monitor devices and networks managed by Cisco APIC controllers. Very early days for this plugin, needs work to finish building the integration.

Daring non-developers
These plugins have very basic functionality, with many hard coded aspects. Expect dramatic instability.

  • OpenDaylight: Monitor devices and networks managed by OpenDaylight. Incomplete functionality, with many hard-coded aspects (e.g., all the nodes it creates are named according to the MAC address of the switches they represent).
  • InfluxDB Time Series Storage (TSS): Store and retrieve timeseries data in an Influx database. Experimental and incomplete.
  • Timescale TSS: Store timeseries data in a Timescale database that OpenNMS can retrieve. Experimental and incomplete.
  • PRIS: Get external information from your inventory into an OpenNMS requisition model. Experimental refitting into plugin form of the standalone PRIS middleware.

Advanced non-developers
May occasionally result in non-catastrophic issues.

  • PagerDuty: Create PagerDuty incidents that correspond to alarms in OpenNMS.

Non-developers who like a challenge
Reasonably useful, but rough around the edges.

  • Cortex TSS: Convert metrics to a Prometheus model and delegate writes and reads to Cortex. Very close to final.