Glossary

acquisition

First step of check execution in the context of the mplugin library. Data is retrieved from the system under surveillance using custom code. This is where the meat of a plugin is. Data acquisition is performed by one or more domain model objects which are usually Resource subclasses.

domain model

One or more classes that abstract the properties of the system under surveillance that are relevant for the check. The domain model code should not be interspersed with secondary aspects like data representation or interfacing with outside monitoring infrastructure.

evaluation

Second step of check execution in the context of the mplugin library. Data generated in the acquisition step is evaluated according to criteria specified in Context objects.

Monitoring plugin API

Documents that define how a Nagios/Icinga compatible plugin must be called and how it should respond. There is a main document and an appendix for Nagios 3 extensions.

perfdata

See performance data.

performance data

Part of the plugin output which is passed to external programs by Nagios.

presentation

Third step of check execution in the context of the mplugin library. Outcomes from the evaluation step are condensed into a compact summary which is suited to inform the admin about relevant system state. Data presentation is the responsibility of Summary objects which also generate the performance data output section.

range

String notation defined in the Monitoring plugin API to express a set of acceptable values. Values outside a range trigger a warning or critical condition.

unit of measure

Property of a metric which is returned in Performance Data and is used for example as axis label in performance graphs. Monitoring plugins should only use base units like s, B, etc. instead of scaled units like days, MiB etc.

uom

See Unit of Measure.