DevProjects/SNMP Data Collection Cleanup

From OpenNMS
Jump to navigation Jump to search

We started to split SNMP data collections and related RRD graph templates in separate files to achieve the following goals:

  • Make it easier to understand which data is collected from which devices and what is supported by default
  • Allow the user to contribute configurations for other devices from a manufacturer
  • Reduce the load on SNMP agents to collect OID groups which are not supported
  • Make it easier and reduce the number of configuration files changed when support for additional devices is added or enhanced
  • Decouple the device and application support which can be monitored by OpenNMS from the OpenNMS software release cycle
  • Allow users to create derivates of application and device support to make them useful in different use cases.
  • Allow users to provide also other resources in the configuration package repository, e.g. Grafana Dashboards specific for those devices and defined metrics.

In long term, it would be reasonable to move support for collecting and monitoring devices by vendors in a configuration package which can have its own lifecycle which is decoupled from the lifecycle of the OpenNMS code base. For the reason, SNMP is built in a tree structure which starts with the common sense the Standard MIB-II, which should be implemented by vendors as a minimum base, we have groups of OIDs which can't be assigned by default to a vendor-specific device which is identified by OpenNMS with the _System Object Identifier (sysoid)_.

For example, the Printer MIB-II is implemented by vendors like HP (.1.3.6.1.4.1.11.2.3.9.1), Kyocera (.1.3.6.1.4.1.1347.) and Lexmark (.1.3.6.1.4.1.641.). For obvious reasons, it does not make sense to add those OIDs supporting the Printer MIB to all devices which support the Standard MIB-II. It is required to assign those OID groups to the Systems which support the Printer MIB.

As soon the Printer MIB OID groups get assigned to a specific vendors data collection configuration you get a dependency between the two files.

To make it more transparent for a user to identify easier possible dependency candidates and give users a hint where they can find generic OID groups which can be assigned to vendor MIBs they get prefixed with "REF_" as a short name for Reference.

Milestones

  1. Reduce unnecessary data collection and split configurations for data collection and RRD graph definitions by vendors or models. Ideally, in mind, they can be distributed as a configuration package.
  2. Split Standard MIB-II configurations which can be reused as a reference in vendor specific MIBs, e.g. Printer MIB or UPS MIB
  3. (optional) Move Vendor or Device Model-specific configuration packages out of the OpenNMS code base in dedicated versioned repositories and gives a user documentation how to install them.

Resources