From OpenNMS

Contents 1 This is Only a Design! 2 Audience 3 Diagram 4 Notes 4.1 The check-interface Element 4.2 The specific-check Element 4.2.1 The perf-object Element 4.3 The key-check element

This is Only a Design!

This article is intended only to document a proposed design. No mechanism has been implemented as of December 2008 for collecting data via NRPE.

Audience

The intended audience for this article is OpenNMS developers who are interested in the prospect of a NRPE collector. The general population of non-develeoper users will not find useful information in this article.

Diagram

Please forgive my UML-ish pidgin, it's been a while since I formally used UML...

Notes

This design is strongly inspired by the SNMP data collection config file design, with a few key modifications. I'm assuming that everybody who has any business reviewing this article is already familiar with datacollection-config.xml, so I'm leaving out the parts that do not differ substantially.

The check-interface Element

NRPE (which is really just Nagios plugins over a TCP transport) lacks an SMI for its performance data, so I have added the notion of a check-interface. This element allows one to describe, in a reusable way, how to execute a plugin and parse the performance data from its output. The check-plugin element has the following attributes:

name (required)

A name that can be referenced within this configuration file. Does not need to be the same as the name by which the plugin is invoked.

plugin-name (required)

The name by which the plugin will be invoked.

perf-record-separator

The string that separates records in the performance data output by this plugin. Defaults to a single space character.

perf-field-separator

The string that separates a performance datum's name from its value or values. Defaults to "=".

perf-field-multival-separator

The string that separates multiple values returned for a single performance datum. Defaults to ";".

perf-field-multival-index

The zero-based index number of the value of a multi-valued datum that should be collected. Defaults to 0.

For example, consider the check_load plugin, which returns performance data like the following:

load1=0.434;0.010;0.100;0; load5=0.445;2.000;5.000;0; load15=0.505;3.000;6.000;0;

For the following check-interface definition:

<check-interface name="loadavg" plugin-name="check_load" perf-record-separator=" " perf-field-separator="=" perf-field-multival-separator=";" perf-field-multival-index="0" />

The above would yield three performance objects available for collection:

load1

0.434

load5

0.445

load15

0.505

The specific-check Element

This element references by name a check-interface element defined in the same NRPE collection definition, and provides specific details of how the plugin described by the check-interface should be invoked. The specific-check element has the following attributes:

implements (required)

A reference to the name attribute of a check-interface element defined in the same nrpe-collection as this element

command-args

A free-form string defining the arguments that should be passed to the check plugin. Defaults to the empty string. Note that it is considered a NRPE best practice for security reasons to disallow plugin arguments

The perf-object Element

This element may appear one or more times as children of a specific-check element. It specifies a single datum that will be collected and persisted. The perf-object element has the following attributes:

key (required)

The performance datum key name to collect. In the check_load example above, this would be one of load1, load5, load15.

alias (required)

The data source name to use when persisting this object's value. NB you should keep this to 19 characters or shorter for RRDTool compatibility

type (required)

How to store this object's value (counter|gauge|string)

The key-check element

Since there is no NRPE equivalent of the SNMP sysObjectID that is persisted as part of a node's intrinsic data, this element exists as a way (borrowed from the NSClient Collector to make the collection of one or more NRPE groups conditional on the result of a gating plugin check that is executed once when the collector starts up and periodically while it is running. This element is equivalent to the specific-check element, but has an added attribute that specifies how often to repeat the check:

implements (required)

References, by name, a check-interface element defined in the same nrpe-collection with this element.

command-args

Optional arguments to pass to the check plugin.

recheck-interval

How often to re-run this key-check, allowing a node's eligibility for part of a collection to be updated at run time. If not specified, this key-check will be run at every collection.