Neues in PNP 0.6.x

PNP 0.6.x Preview

Die Arbeit an der Version 0.6.x ist in vollem Gange.

Mit Version 0.6.x steigen wir von Subversion auf GIT um. Der Sourcecode ist bereits auf Sourceforge erhältlich.

http://pnp4nagios.git.sourceforge.net

Bisher umgesetzte Funktionen:

zurück zur Übersicht | Anforderungen

Über PNP

→ Read more...

Die Kunst Daten zu sammeln

PNP unterstützt mehrere Arten, die Performance-Daten zu verarbeiten. Die einzelnen Modi unterscheiden sich durch ihre Komplexität und die zu erwartende Performance.

Das folgende Bild zeigt die Verbindungen zwischen Nagios, PNP und RRDtool

Nagios führt für jeden Host- und jeden Service, dessen Performance-Daten gesammelt werden sollen, einen Befehl aus. Abhängig vom gewählten Modus werden die Daten entweder direkt an ein Perl-Script übergeben oder in temporäre Dateien geschrieben und später verarbeitet. process_perfdata.pl legt die Datei in XML-Dateien ab und speichert sie mit Hilfe von RRDtool in RRD-Dateien.

Bevor Ihr euch auf einen Modus festlegt, lest euch alles durch und entscheidet selbst, welcher Weg für eure Installation der Beste ist.

→ Read more...

Upgrade auf Version 0.6.x

Das Web-Frontend ist komplett neu geschrieben worden und basiert nun auf dem PHP MVC Framework Kohana. Somit ergeben sich grundlegend andere Abhängigkeiten, die dringend vor der Installation geprüft werden müssen.

Anmerkung: Ein Upgrade läuft zuerst wie eine Neuinstallation. Anschließend sind einige Anpassungen durchzuführen, die weiter unten beschrieben sind.

PNP 0.4.x wurde ohne weitere Angabe von Optionen beim Aufruf von ./configure unterhalb einer Nagios-Installation unter /usr/local/nagios installiert.

PNP 0.6.x wird bei Angabe keiner weiteren Optionen unter /usr/local/pnp4nagios installiert, ist also wie Nagios als eigenständige Applikation zu sehen.

Anmerkung: Es reicht aus, die *.rrd-Dateien vom alten ins neue Verzeichnis zu kopieren. Sie enthalten die eigentlichen Daten. Die *.xml-Dateien werden jedes Mal neu angelegt, wenn Performance-Daten verarbeitet werden, denn sie enthalten lediglich Meta-Informationen. Außerdem hat sich die interne Struktur geändert, so dass sie sowieso nicht nutzbar sind.

→ Read more...

Installation

Im Folgenden wird die Installation von PNP beschrieben. Dabei wird davon ausgegangen, dass Nagios aus den Sourcen übersetzt und im Verzeichnis /usr/local/pnpnagios installiert wurde.
Achtung: Die Beschreibung bezieht sich auf die Developer-Version PNP 0.6.0.
Bitte vergessen Sie nicht, dass PNP nach der Installation noch konfiguriert werden muss.

→ Read more...

Konfiguration

Im folgenden wird die Konfiguration der bereits erwähnten Arten der Performance-Daten Verarbeitung genauer erklärt.

Die bevorzugte Methode der PNP Entwickler ist der “Bulk Mode mit NPCD und npcdmod”.

→ Read more...

Prüfen der Installation

Wenn bis jetzt alles sauber funktioniert hat, kann PNP zum ersten Mal im Browser aufgerufen werden. Bei der Installation mit den Standardeinstellungen erfolgt der Aufruf über http://<Servername>/pnp4nagios/.

Beim ersten Aufruf sieht man die Seite “PNP4Nagios Environment Tests”, die verschiedene Tests von notwendigen Komponenten enthält. Offenkundig sollten alle Tests erfolgreich verlaufen, bevor es weitergehen kann. Bitte beachten Sie die Hinweise auf der Seite.

Sind alle Tests erfolgreich verlaufen, so kann die Datei pnp4nagios/share/install.php gelöscht oder umbenannt werden. Erst dann ist das Webinterface erreichbar.

Alternativ kann eine Datei pnp4nagios/share/install.ignore angelegt werden, um den Aufruf des Installers nach weiteren Updates zu ignorieren.

Ohne weitere Optionen sucht PNP nach RRD- und XML-Dateien in pnp4nagios/var/perfdata/ und zeigt alle Graphen des ersten Hosts in der Übersicht an.

ACHTUNG: Direkt nach dem (Neu-)Start von Nagios nach dem Aktivieren der Verarbeitung von Performance-Daten wird der Aufruf im Browser zu Fehlermeldungen führen, weil zunächst Performance-Daten gesammelt und in den RRD-Dateien abgelegt werden müssen. Abhängig vom Check-Intervall kann es einige Zeit dauern, bis die ersten Graphen angezeigt werden können.

→ Read more...

verify_pnp_config

Bei Problemen kann das Perl-Script verify_pnp_config.pl im scripts-Verzeichnis helfen, mit dem neben der Konfiguration auch die Performance-Daten von Hosts und Services geprüft werden können. Es kann sowohl vor als auch während des Betriebs von PNP genutzt werden.

* Hinweis *: Die Angaben beziehen sich auf verify_pnp_config v0.1.24, das über http://www.pnp4nagios.org/pnp/dwnld in der Version 0.6.7 zu finden ist. Ältere Versionen haben teilweise weniger Optionen, so dass es in den Beschreibungen der einzelnen Optionen Hinweise auf die PNP-Version gibt.

* Hinweis *: In PNP 0.6.4 fehlt eine Zeile im Script, was zu einem Fehler führt, so dass Sie vorher diese Zeile einfügen sollten:

     $CPcfg{'$conf[\'max_age\']'} = 'n;^\(?[\d\* ]+\)?$';
     $CPcfg{'$conf[\'temp\']'} = 'd;;';
     $CPcfg{'$conf[\'base_url\']'} = "S;.+;";   # <-- diese Zeile einfügen
     $CPcfg{'$conf[\'nagios_base\']'} = "S;.+;";
     $CPcfg{'$conf[\'allowed_for_service_links\']'} = 'S;[\S,]+;';

* Hinweis *: die “langen” Optionen beginnen immer mit zwei ”-”. Leider ist das im Text nicht zu erkennen.

Die einfachste Form des Aufrufs zur Überprüfung der Konfiguration lautet:

./verify_pnp_config.pl -m <Modus>

wobei <Modus> durch den benutzen PNP-Modus zu ersetzen ist (sync, bulk oder NPCD).

Das Script liefert beim Aufruf mit der Option –h bzw –help u.a. die folgende Ausgabe:

-h, --help        print these lines
-b, --basedir=s   Nagios Base directory (default: /usr/local/nagios)
-B, --binary=s    Nagios binary (default: nagios)
-c, --config=s    Nagios main config file (default: /usr/local/nagios/etc/nagios.cfg)
-m, --mode=s      PNP mode ("sync", "bulk", "NPCD")
-l, --logfile=s   check configure log file
-D, --pnpdir=s    PNP root dir
-N, --npcdcfg=s   PNP config file for NPCD mode (default: /usr/local/pnp4nagios/etc/npcd.cfg)
-P, --ppcfg=s     process_perfdata config file (default: /usr/local/pnp4nagios/etc/process_perfdata.cfg)
-C, --cpcfg=s     PNP config file (config.php)
-p, --precheck    use config files instead of objects cache
-r, --rrdtool=s   specify the location of the RRDtool binary
-R, --RRDpath=s   specify the perfdata directory (default: /usr/local/pnp4nagios/var/perfdata) or "no" for no check
-U, --resource=s  location of the resource config file (default: /usr/local/nagios/etc/resource.cfg)
-M, --monitor=s   specify the monitoring product (default: nagios, may be "icinga")
-L, --layout=s    specify a layout (Nagios2, Nagios3, SuSE, Fedora)
-T, --template=s  specify the path to the templates directory (default /usr/local/pnp4nagios/share/templates.dist)
-u, --user=s      user of the perfdata directory
-g, --group=s     group of the perfdata directory 	
-q, --quiet       quiet mode, non-zero return code will indicate errors
-o, --object=s    Nagios object (host name, service description)
-t, --time        show warnings if RRDfiles are too old
-s, --skip        skip check of installed packages
-n, --native      show messages in native language (so far "es" or "de")
-e, --english     show english messages/links
-d, --debug       some debugging output
-I, --info        show information about compile time variable settings

Das Nagios-Programm und der Zugriff auf die Hauptkonfigurationsdatei nagios.cfg werden immer benötigt. Bei vom Standard abweichenden Pfaden für Nagios gibt es daher die Möglichkeit, über die Option -L ein anderes Layout vorzugeben. Je nach Distribution bzw. Version sollte einer der Werte “suse” oder “fedora” bzw. “nagios2” oder “nagios3” funktionieren (u.a. bei Debian und Ubuntu).
Falls das alles nichts hilft, kann man sowohl das Basisverzeichnis (-b bzw. –basedir), den Namen des Programms (-B bzw. –binary) als auch den Standort der Hauptkonfigurationsdatei (-c bzw. –config) und der Ressource-Datei (-U bzw. –resource) mit Hilfe von Optionen anzugeben. Wenn der Name des Programms mit einem ”/” beginnt, dann wird dieser Wert als absolute Angabe betrachtet und unverändert übernommen. Ohne ”/” ergibt sich der Pfad aus dem Basisverzeichnis mit angehängtem “bin” und dem Binary-Namen.

Ohne Angabe von Optionen wird die Hilfeseite ausgegeben, so dass entweder der Modus oder ein Objekt als Parameter anzugeben sind.

Mit der Option -m (–mode) wird dabei der PNP-Modus angegeben, dessen Einstellungen untersucht werden. Dabei erlaubt die Option -l <Dateiname> bzw. –logfile=<Dateiname> die Prüfung der Konfiguration während der Installationsphase. Sie müssen bereits ./configure (ggf. mit zusätzlichen Optionen) ausgeführt haben. Dadurch wird die Datei config.log erstellt, deren Name als Parameter übergeben wird. Das Script prüft, ob die Software-Voraussetzungen erfüllt werden bzw. ob verschiedene Einstellungen korrekt vorgenommen wurden. Dazu gehört auch ein Aufruf des RRDtool-Programms, so dass ggf. die Option -r (–rrdtool) benutzt werden muss, wenn es nicht unter /usr/bin/rrdtool zu finden ist.

Das Script prüft, ob für Dateien/Verzeichnisse im perfdata-Verzeichnis Benutzer und Gruppe mit den Werten übereinstimmen, die in der nagios.cfg eingetragen sind. Außerdem wird geprüft, ob innerhalb der xml-Dateien Return-Codes des RRDtools gefunden werden, die auf einen Fehler hinweisen. Dabei kann mit der Option -R (–RRDpath) das Verzeichnis angegeben werden, unter dem die RRD-Dateien abgelegt sind, falls es vom Standard abweicht. Falls keine Prüfung gewünscht wird, ist “no” als Verzeichnis anzugeben. Mit den Optionen -u (–user) und -g (–group) können Benutzer und Gruppe des Perfdata-Verzeichnisses angegeben werden, falls diese vom Nagios-Benutzer abweichen sollten.

Nach der Installation können die Änderungen in der nagios.cfg mit der Option –p (–precheck) überprüft werden, bevor ein Neustart erfolgt ist. Das ist sinnvoll, um ggf. fehlerhafte Einträge zu korrigieren, ohne Nagios jeweils neu starten zu müssen.

Beim Aufruf mit der Option -o, der als Parameter eine Zeichenkette folgt, werden alle Hosts bzw. Services mit diesem Namen sowie die Informationen zu Performance-Daten ausgegeben. Die Zeichenkette sollte in Anführungszeichen gesetzt werden. Falls keine bzw. fehlerhafte Performance-Daten vorhanden sind, gibt es entsprechende Meldungen.

Durch das Anhängen eines Semikolons werden nur Hosts mit der angegebenen Zeichenkette untersucht, durch Voranstellen nur Services. Enthält die Zeichenkette mittendrin ein Semikolon, dann wird der erste Teil als Hostname und der zweite als Servicebeschreibung betrachtet und die Auswertung auf diesen Host mit dem entsprechenden Service beschränkt:

Ab PNP-Version 0.6 hat sich die Verzeichnisstruktur geändert, so dass alle Dateien unter einem separaten Verzeichnis liegen. Mit der Option -D (–pnpdir) kann man einen von /usr/local/pnp4nagios abweichenden Pfad für das PNP-Basisverzeichnis angeben. Diese Einstellung wirkt sich auch auf die Optionen ”-N”, ”-P” und ”-C” aus, so dass dort ggf. keine Werte angegeben werden müssen.

Im NPCD-Modus kann durch die Option -N (–npcdcfg) der Name der Konfigurationsdatei angegeben werden, falls Name oder Ort nicht dem Standard entspricht (/usr/local/pnp4nagios/etc/npcd.cfg).

Mit der Option -P (–ppcfg) wird der Name der Konfigurationsdatei für process_perfdata.pl angegeben, falls Name oder Ort vom Standard abweicht (/usr/local/pnp4nagios/etc/process_data.cfg).

Mit der Option -C (–cpcfg) wird der Name der Konfigurationsdatei config.php angegeben, falls Name oder Ort vom Standard abweicht (/usr/local/pnp4nagios/etc/config.php).

Durch die Option -M (–monitor) kann das Produkt angegeben werden, von dem PNP die Daten bekommt. Per Default ist das Nagios, inzwischen wird auch Icinga unterstützt. Teilweise müssen auch die Optionen -b, -B und -c benutzt werden.

Teilweise entstehen beim Aendern von Templates Fehler, die man in der Web-GUI nicht so schnell findet. Mit der Option -T werden die Template-Dateien auf Fehler geprüft. Als Parameter ist der Pfad zum Template-Directory anzugeben.

Normalerweise wird geprüft, ob bestimmte Pakete installiert sind. Falls es dabei Schwierigkeiten gibt (oder man sicher ist, dass alle benötigten Pakete vorhanden sind), kann man die Prüfung durch die Option -s (–skip) überspringen.

Mit der Option -n (–native) gefolgt von “es” or “de” können spanische oder deutsche Meldungen gewählt werden.

Die Option -e (–english) erzwingt die Anzeige von englischen Meldungen, selbst wenn abweichende Spracheinstellungen erkannt werden.

Durch Angabe der Option -d bzw. –debug werden zusätzliche Zeilen ausgegeben, die bei der Fehlersuche helfen können, -q bzw. –quiet unterdrückt sämtliche Ausgaben.

Die Option -I (–info) zeigt die Inhalte von Variable wie z.B. prefix, datadir und anderen Dingen, die Sie vielleicht beim Aufruf von './configure' geändert haben. In einigen Fällen möchten wir diese Werte wissen und mit Hilfe dieser Option geht es einfacher als wenn Sie verschiedene Dateien durchsuchen müßten. Diese Option gibt es seit PNP 0.6.7.

Die Ausgaben selbst beginnen mit einem Buchstaben, der genauere Informationen ueber die Art der Ausgaben gibt:

[I] Informationen zu Einstellungen, …
[A] durchzuführende Aktionen
[W] Warnung: beeinträchtigt nicht die Arbeitsweise von PNP
[E] Fehlermeldung: PNP wird nicht korrekt arbeiten, solange das Problem besteht
[H] Hinweis: es ist ratsam, die angegebene Dokumentation zu lesen
[D] Debugging-Meldung, die hoffentlich zur Fehlerbehebung führt

zurück zur Übersicht | das Web-Frontend

Das Nagios Web Frontend

PNP soll natürlich schnell erreichbar sein. Man möchte nicht lange nach den richtigen Graphen suchen.

Nagios selbst bietet die Möglichkeit, externe URLs über die sogenannte Extended Info Config einzubinden. Da es in diesem Bereich eine Änderung zwischen Nagios 2.x und der Version 3.0 gibt, wird anschließend auf beide Versionen getrennt eingegangen.

→ Read more...

PNP Web Frontend

Das Verhalten des PNP-Web-Frontend lässt sich über die Config-Datei etc/config.php beeinflussen. Diese Datei wird bei Updates von PNP immer wieder überschrieben, da die meisten Pfade und Optionen bereits durch ./configure ermittelt werden.

Eigene Anpassungen sollten daher in der Datei etc/config_local.php erfolgen. Sollte die Datei noch nicht existieren, kann die config.php als Vorlage verwendet werden.

→ Read more...

Timeranges

In der Übersicht zeigt PNP fünf Zeitbereiche, die frei in der config.php definiert werden können.

Es gibt aber auch die Möglichkeit, die Zeitbereiche über die URL zu beeinflussen. Dies ist hilfreich, wenn z.B. automatisch PDF-Dokumente erstellt werden sollen

Die Zeitbereiche werden über die Optionen start und end definiert.

Beispiel:

 pnp4nagios/graph?host=<hostname>&srv=<servicedesc>&start=-1week

Der Startzeitpunkt der Graphen wird somit, ausgehend vom aktuellen Datum, um eine Woche nach hinten verschoben. Der Endzeitpunkt bleibt auf dem aktuellen Zeitstempel. Aber auch end lässt sich über diesen Weg beeinflussen, wobei beide Optionen auch einzeln manipuliert werden dürfen.

start end view Ergebnis
Alle Ansichten enden mit der aktuellen Zeit
x Alle Ansichten beginnen mit dem angegebenen Datum
x Alle Ansichten enden mit dem angegebenen Datum
x x Eine Ansicht zwischen den beiden Zeitangaben
x Eine Ansicht endet mit der aktuellen Zeit
x x Eine Ansicht beginnt mit dem angegebenen Datum
x x Eine Ansicht endet mit dem angegebenen Datum

Beispiele zur Datumsangabe:

Format Beschreibung
2009W04 4. KW 2009
1.5.2009 1. Mai 2009
-1 day Einen Tag zurück
-3 weeks 3 Wochen zurück
-1 year Ein Jahr zurück
yesterday Gestern

zurück zur Übersicht | Pages

Pages

„pages“ bieten die Möglichkeit, Grafiken von verschiedenen Hosts/Services auf einer Seite zusammenzufassen. Auf diese Weise können z.B. die Übertragungsraten der Netzwerk-Interfaces aller Tape-Libraries dargestellt werden. Innerhalb der Definitionen sind reguläre Ausdrücke möglich, so dass – entsprechende Namen vorausgesetzt - mit wenig Aufwand viel erreicht werden kann. Das Verzeichnis, das in config.php durch den Konfigurationseintrag „$conf['page_dir']“ angegeben wurde, enthält ein oder mehrere Dateien mit der Endung „.cfg“.

Kommentare beginnen mit einem '#' und sind auch innerhalb einer Zeile möglich. Jede Datei enthält eine „page“-Definition, die neben dem Namen der Seite festlegt, ob die nachfolgenden Grafikdefinitionen reguläre Ausdrücke enthalten.
Die Bezeichnung hinter page_name erscheint in der Liste der verfügbaren Seiten und wird als Titel im Browser angezeigt. Achtung: “host_name” und “service_desc” beziehen sich auf die Namen der Dateien im perfdata-Ordner, nicht auf die Nagios-Bezeichnungen. Leerzeichen werden durch Unterstriche (“_”) ersetzt.

define  page  {
        use_regex 1		# 0 = keine regulären Ausdrücke, 1 = reguläre Ausdrücke
        page_name Test-Seite	# Beschreibung der Seite
}

Danach folgen ein oder mehrere „graph“-Definitionen:

define graph {
        host_name       host1,host2,host3
        service_desc    Current_Load
}

Achtung: Damit die oben gezeigte Liste von Host-Namen funktioniert, muss use_regex 0 gesetzt sein!

define graph {
        host_name       host4
        service_desc    Current_Users
}

Und jetzt mit regulären Ausdrücken. Zuerst alle Hosts, deren Name mit „Tape“ beginnen:

define graph {
        host_name       ^Tape
        service_desc    Traffic
}

alle Hosts, deren Namen mit “00” enden

define graph {
        host_name       00$
        service_desc    Load
}

alle Services des localhost, deren Namen ein „a“ oder „o“ enthalten:

define graph {
        host_name       localhost
        service_desc    a|o
}

alle Services, die im Namen nach einem „_“ (mindestens) drei Ziffern haben auf allen Hosts, deren Namen mit „UX“ beginnen:

define graph {
        host_name       ^UX
        service_desc    _\d{3}
}

zurück zur Übersicht | Datenexport

Datenexport

PNP bietet über den xport Controller Zugriff auf die RRD-Daten. Dabei kann das Ausgabeformat gewählt werden. Zur Zeit sind die Formate xml, json und csv realisiert.

Aufgerufen wird der Controller über die URL

/pnp4nagios/xport/<format>?host=<hostname>&srv=<servicedesc>

wobei <format> durch das jeweils gewünschte Format zu ersetzen ist.

zurück zur Übersicht | Templates

Was sind Templates ?

PNP benutzt Templates, um das Aussehen der RRD-Graphen zu beeinflussen.

Dabei bestimmt das verwendete check_command, welches Template zur Darstellung herangezogen wird. Im Folgenden wird beschrieben, wo Templates gespeichert werden und wie die Entscheidung für das “richtige” Template getroffen wird.

→ Read more...

Custom Templates

Wie bereits unter ”Was sind Templates ?” beschrieben, ist die Darstellung der Graphen abhängig vom verwendeten Check-Command.

Es gibt jedoch Situationen, in denen dieses Verhalten übersteuert werden muss.

→ Read more...

Advanced

→ Read more...

RRDtool Cache Daemon

In großen Installationen wird man über kurz oder lang feststellen, dass die Verarbeitung der Performance-Daten eine recht hohe I/O-Last zur Folge hat. RRDtool muss extrem viele Updates auf Disk schreiben, kann dabei jedoch den Disk-Cache nicht optimal ausnutzen.

Eine Optimierung stellt das Sammeln und Sortieren der Daten dar. Es ist für das System effektiver, viele Updates im Block in eine RRD-Datenbank zu schreiben. Der Disk-Cache kann dabei effektiver genutzt werden.

In der aktuellen RRDtool-Version ( SVN trunk 1550+ ) ist der rrdcached enthalten, der genau diese Situation verbessern soll.

An dieser Stelle möchte ich mich bei Florian octo Forster, Kevin Brintnall und Tobi Oetiker bedanken. Die Entwicklung dieses Daemons wurde vorbildlich auf der rrd-developers Mailingliste koordiniert.

→ Read more...

NPCD

NPCD (Nagios-Perfdata-C-Daemon) wurde geschrieben, um die asynchrone Bearbeitung von Nagios Performance-Daten zu ermöglichen.

→ Read more...

check_procs ist ein Beispiel für ein Plugin, das keine Performance-Daten ausgibt:

./check_procs -a ndo2db -w 1: -c 0:
PROCS OK: 2 processes with args 'ndo2db'

Mit dem folgenden Wrapper-Script kann das geändert werden

check_procs.sh

#!/bin/bash
LINE=`/usr/local/nagios/libexec/check_procs $*`
RC=$?
COUNT=`echo $LINE | awk '{print $3}'`
echo $LINE \| procs=$COUNT
exit $RC

Nun wird die Zahl zusammen mit einer Bezeichnung ausgegeben.

./check_procs.sh -a ndo2db -w 1: -c 0:
PROCS OK: 2 processes with args 'ndo2db'| procs=2

2.6. Performance-Daten

Performance-Daten von Nagios sind definiert als “alles hinter dem | des Plugin-Outputs” - nähere Einzelheiten dazu, wie diese Daten in Logfiles umgeleitet werden, gibt es in der Nagios-Dokumentation. Trotz allem ist es die Aufgabe des Plugin-Schreibers, dass die Performance-Daten in einem “Nagios-Plugin”-Format vorliegen. Dies ist das erwartete Format:

'Bezeichnung'=Wert[UOM];[warn];[crit];[min];[max]

Anmerkungen:

  1. Leerzeichen trennen Listen von Bezeichnung/Werte-Paaren
  2. Bezeichnungen können beliebige Zeichen enthalten
  3. die Bezeichnung muss in Apostrophs eingeschlossen sein, wenn diese = oder Leerzeichen enthält, ansonsten sind die Apostrophs optional
  4. die Länge der Bezeichnung ist beliebig, aber idealerweise sind die ersten 19 Zeichen eindeutig (aufgrund einer Beschränkung in RRD). Bitte beachten Sie, dass es eine Längenbegrenzung bei der Menge von Daten gibt, die von NRPE an Nagios geliefert werden kann
  5. um ein Apostroph darzustellen, nutzen Sie zwei einzelne Apostrophs
  6. warn, crit, min und/oder max können leer sein (z.B. wenn der Schwellwert nicht definiert ist oder wenn min oder max nicht zutreffen). Nachfolgende, nicht gefüllte Semikola können entfallen
  7. min und max sind nicht erforderlich, wenn UOM = %
  8. Wert, min und max sind aus der Klasse [-0-9.] (Ziffern, Minuszeichen und Dezimalpunkt). Alle müssen das gleiche UOM benutzen
  9. warn und crit sind im “Range”-Format (siehe Abschnitt 2.5 der Original-Dokumentation). Alle müssen das gleiche UOM benutzen.
  10. UOM (unit of measurement, Maßeinheit) ist eins von:
    • keine Einheit angegeben - angenommen wird eine Zahl (int oder float) von Dingen (z.B. Benutzer, Prozesse, Load)
    • s - Sekunden (auch us, ms)
    • % - Prozent
    • B - Bytes (auch KB, MB, TB; GB?)
    • c - ein fortlaufender Zähler (z.B. Bytes, die über ein Interface übertragen werden)

Es bleibt Drittanbietern überlassen, aus den Performance-Daten Graphen zu erzeugen.

Quelle: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN201