Menu
- PNP4Nagios 0.6.x
- PNP4Nagios 0.4.x
PNP benötigt zwingend gültige Performancedaten von Nagios Plugins.
Was sind also diese Performancedaten?
Die Ausgabe eines Nagios Plugins darf bis Nagios 2.x maximal eine Zeile betragen. Diese Ausgabe wird, wenn das Plugin Performancedaten liefert, in zwei Teile zerlegt. Als Trennzeichen dient dabei das Pipe “|” Symbol.
Beispiel check_icmp :
OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;
daraus ergibt sich der Output auf der linken Seite des Pipe Symbols
OK - 127.0.0.1: rta 2.687ms, lost 0%
und die Performancedaten
rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;
Wie man unschwer erkennt, sind die Performancedaten auf die maschinelle Verarbeitung ausgelegt. Das Format ist in den Developer Guidelines festgelegt, soll aber hier noch einmal kurz erläutert werden.
rta=2.687ms;3000.000;5000.000;0; | | | | | | | |----|--|----|---------|-----|-|----- * Label |--|----|---------|-----|-|----- * Aktueller Wert |----|---------|-----|-|----- Einheit ( UOM = UNIT of Measurement ) |---------|-----|-|----- Warning Schwellwert |-----|-|----- Critical Schwellwert |-|----- Minimum Wert |----- Maximum Wert
Mit * gekennzeichnete Werte müssen vorhanden sein. Alle anderen Werte sind optional.
Mehrere Datenreihen werden durch Leerzeichen getrennt. Die eigentlichen Daten dürfen also keine Leerzeichen enthalten. Soll das Label Leerzeichen enthalten, so müssen diese in einfache Hochkomma eingeschlossen werden.
PNP ist unter der GPL 2 lizensiert.
Die Entwicklung von PNP wird auf Sourceforge.Net organisiert. PNP ist dort unter dem Projektnamen PNP4nagios registriert.
Die jeweils aktuelle Version findet ihr im Downloadbereich.
Wer noch aktueller sein möchte, kann auch die jeweils letzte Entwickler-Version benutzen.
Die Entwickler ( devel ) Version wird täglich automatisch aus dem SVN Repository erstellt. Die Seite ist nur in englischer Sprache verfügbar, aber dafür immer aktuell.
Bitte stellen Sie VOR Support-Anfragen sicher, dass Sie die unter Prüfen der Installation genannten Punkte geprüft haben.
Deutscher Support ist im Nagios Portal zu erhalten. Über Beiträge im dortigen PNP-Forum werden die Entwickler sofort per Mail informiert. Bitte nutzen Sie zuerst die Suchfunktion.
Bitte füllen Sie nach der Anmeldung als Benutzer Ihr Profil aus. Auf diese Weise entfallen Nachfragen bzgl. eingesetztem Betriebssystem, PNP-Version u.ä. Bitte geben Sie ebenfalls an, ob Sie PNP aus einem Package oder aus den Sourcen installiert haben.
Erfolgreich gelöste Probleme kennzeichnen Sie bitte mit einem [solved] in der Betreffzeile des ersten Beitrags. Auf diese Weise erleichtern Sie anderen Benutzern das Finden von Lösungen zu ihrem Problem.
Weiterhin können die Mailinglisten auf Sourceforge verwendet werden. Dort ist es jedoch üblich, Fragen auf Englisch zu stellen. Bitte geben Sie dort das verwendete Betriebssystem und die eingesetzte PNP-Version an.
pnp4nagios-users: Die Users Liste für allgemeine Fragen zur Konfiguration.
pnp4nagios-devel: Die Devel Liste für Anregungen und Fehler Reports.
pnp4nagios-checkins: Auf der Checkins Liste werden Änderungen im SVN Repository automatisch veröffentlicht.
Die Performance-Daten werden mit Hilfe von RRDtool in sogenannten Round-Robin-Datenbanken gespeichert, die wie ein Ringpuffer funktionieren. Das bedeutet, dass nach einer gewissen Zeit die ältesten Daten “hinten” herausfallen und “vorne” durch neue ersetzt werden.
Verschiedene Zeitintervalle innerhalb der Datei sorgen für unterschiedliche Auflösungen. In der Standardeinstellung können die Daten für die letzten zwei Tage im Minutenabstand abgelegt werden, für zehn Tage im 5-Minutenabstand, für 90 Tage im 30-Minutenabstand und für 4 Jahre im 6-Stundenabstand. Die Vergrößerung des Intervalls bewirkt, dass auch die Daten über das jeweils größere Intervall hinweg gemittelt werden. Das führt automatisch dazu, dass Spitzen nicht mehr so deutlich zu sehen sind. Das ist kein Fehler von PNP, sondern eine Eigenheit von RRDtool.
Durch die Speicherung in diesem Format ändert sich die Dateigröße nach dem Anlegen nicht mehr. Pro Datenreihe werden ca. 400 KB benötigt.
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.
Der “default Mode” ist der einfachste und am leichtesten einzurichten. Nagios ruft für jeden Service zusätzlich das Perl-Script process_perfdata.pl auf, um die Daten zu verarbeiten.
Der default-Mode funktioniert sehr gut bis ca. 2000 Services in einem Intervall von 5 Minuten.
Im Bulk-Mode schreibt Nagios die benötigten Daten in eine temporäre Datei. Nach Ablauf einer definierten Zeit wird die Datei an einem Stück abgearbeitet und gelöscht.
Die Anzahl der Aufrufe von process_perfdata.pl reduziert sich um ein Vielfaches. Abhängig von der Zeit und den gesammelten Daten werden wesentlich weniger Systemaufrufe ausgeführt. Dafür läuft process_perfdata.pl länger.
Hinweis Bei diesem Modus sollte man die Laufzeit von process_perfdata.pl im Auge behalten. So lange, wie process_perfdata.pl zum Verarbeiten der Daten benötigt, so lange kann Nagios keine Checks ausführen.
Auszug aus var/perfdata.log:
2007-10-18 12:05:01 [21138] 71 Lines processed 2007-10-18 12:05:01 [21138] .../spool/service-perfdata-1192701894-PID-21138 deleted 2007-10-18 12:05:01 [21138] PNP exiting (runtime 0.060969s) ...
71 Zeilen wurden in 0,06 Sekunden verarbeitet. Das ist das Datenvolumen bei ca. 2000 Services und der Verarbeitung im 10-Sekunden-Intervall. Wir haben Nagios also genau für 0.06 Sekunden blockiert.
Dies ist der komplizierteste Weg, jedoch auch der performanteste.
Nagios benutzt wieder eine temporäre Datei, um die Daten zu speichern, und führt nach Ablauf der Zeit wieder ein Command auf. Jedoch wird die Datei nicht sofort von Process_perfdata.pl verarbeitet, sondern in ein spool-Verzeichnis verschoben. Da das verschieben einer Datei im gleichen Filesystem so gut wie keine Zeit beansprucht, ist Nagios sofort wieder in der Lage, wichtige Arbeiten auszuführen.
Der NPCD ( Nagios Performance C Daemon ) überwacht nun das Verzeichnis auf neue Dateien und übergibt diese an process_perfdata.pl. Die Verarbeitung der Performancedaten ist also komplett von Nagios entkoppelt. NPCD wiederum ist in der Lage, zum Verarbeiten der Daten mehrere Threads zu starten.
Welchen der beschriebenen Wege ihr verwendet, hängt also stark von der Größe der Nagios-Installation ab. Die verwendeten Begriffe werden euch aber in der Dokumentation immer wieder über den Weg laufen.
Die Download Seite ist nur in Englisch verfügbar und wird automatisch aus dem SVN Repository erzeugt.
Zum Download (en)
Im Folgenden wird die Installation von PNP beschrieben. Dabei wird davon ausgegangen, dass Nagios aus den Sourcen übersetzt und im Verzeichnis /usr/local/nagios installiert wurde.
Achtung: Die Beschreibung bezieht sich auf PNP 0.4.14. Hinweise auf die jeweils aktuelle Version gibt es hier.
Bitte vergessen Sie nicht, dass PNP nach der Installation noch konfiguriert werden muss.
Die Installation von PNP wird wie bei Nagios auch über Makefiles gesteuert. Dabei wird durch den Aufruf von ./configure das System analysiert und die ermittelten Werte in Makefiles übernommen.
Als User root wird PNP in /usr/local/src entpackt.
cd /usr/local/src wget http://downloads.sourceforge.net/pnp4nagios/pnp-0.4.14.tar.gz tar -xvzf pnp-0.4.13.tar.gz cd pnp-0.4.13
Im Verzeichnis pnp-<version>, in unserem Fall pnp-0.4.14, wird nun ./configure aufgerufen.
./configure
Es laufen einige Zeilen über den Bildschirm. Wichtig ist die Ausgabe zum Schluss.
*** Configuration summary for pnp 0.4.14 *** General Options: ------------------------- ------------------- Nagios user/group: nagios nagios Install directory: /usr/local/nagios HTML Dir: /usr/local/nagios/share/pnp Config Dir: /usr/local/nagios/etc/pnp Path to rrdtool: /usr/bin/rrdtool (Version 1.2.15) RRDs Perl Modules: FOUND (Version 1.2015) RRD Files stored in: /usr/local/nagios/share/perfdata process_perfdata.pl Logfile: /usr/local/nagios/var/perfdata.log Perfdata files (NPCD) stored in: /usr/local/nagios/var/spool/perfdata/
Die angezeigten Pfade sollten nun geprüft werden. Sollten die gezeigten Werte nicht passen, kann durch einen erneuten Aufruf von ./configure mit den passenden Optionen Abhilfe geschaffen werden.
ACHTUNG: Nachdem es immer wieder Schwierigkeiten gibt: “Path to rrdtool” bedeutet inkl. Namen des Binary! Bei Bedarf kann man das beim ./configure als Parameter angeben:
./configure --with-rrdtool=/usr/local/rrdtool-1.2.xx/bin/rrdtool
./configure --help
zeigt, welche Optionen möglich sind.
Achtung: Falls Nagios nicht unter /usr/local/nagios installiert ist und insbesondere bei der Verwendung von vorkonfigurierten Nagios-Packages reicht der Aufruf von /configure ----prefix=<Nagios-Home>
im Allgemeinen NICHT aus, um PNP korrekt zu installieren. Wichtig sind in diesem Fall die Optionen am Ende der configure-Hilfeseite!
Beispiel für Icinga:
USER=icinga GROUP=icinga PREFIX=/usr/local/icinga ./configure \ --with-nagios-user=$USER \ --with-nagios-group=$GROUP \ --prefix=$PREFIX \ --datarootdir=$PREFIX/share/pnp \ --with-rrdtool=/usr/bin/rrdtool \ --sysconfdir=$PREFIX/etc/pnp \ --with-perfdata-dir=$PREFIX/share/perfdata \ --with-perfdata-logfile=$PREFIX/var/perfdata.log \ --with-perfdata-spool-dir=$PREFIX/var/spool/perfdata
Ein
make all
kompiliert nun die in C geschriebenen Komponenten wie NPCD
make install
kopiert alles an die richtige Stelle im Filesystem. Die Pfade wurden ja beim ./configure bereits gezeigt.
Optional kann noch
make install-config
aufgerufen werden. Damit werden Config-Files für process_perfdata.pl und npcd nach etc/pnp kopiert.
Wir das INIT Script für den NPCD benötigt so sorgt
make install-init
für die Installation nach /etc/init.d
Zusammenfassen lassen sich diese einzelnen Commands durch
make fullinstall
Das Update funktioniert genauso wie die Installation. Bitte beachten Sie, dass Sie beim ”./configure” die gleichen Optionen wie bei der Erstinstallation benutzen!
Bitte prüfen Sie außerdem, ob Sie Änderungen im Verzeichnis share/pnp/templates.dist
vorgenommen haben. Eigene Templates sollten im Ordner share/pnp/templates
abgelegt werden.
Achtung: Wenn Sie in der Datei config.php Änderungen vorgenommen haben, sollten Sie diese Datei sichern, bevor sie bei einem “make install-config” überschrieben wird.
PNP ist noch nicht offiziell als Debian Paket erhältlich. Sven Velt arbeitet jedoch daran, daß sich dies ändert.
Debian Pakete findet ihr auf http://www.velt.de/tags/nagios-pnp
Nach der Installation sind einige Komponenten von PNP an die passenden Stellen im Dateisystem kopiert worden.
Im Folgenden sind dies die PHP-Files für das Web-Frontend in
/usr/local/nagios/share/pnp
Der Datensammler process_perfdata.pl in
/usr/local/nagios/libexec
Beispiel-Config-Files mit der Dateierweiterung -sample
in
/usr/local/nagios/etc/pnp
Die Config-Datei config.php für das Web-Frontend in
/usr/local/nagios/etc/pnp
Im folgenden wird die Konfiguration der bereits erwähnten Arten der Perfomancedaten Verarbeitung genauer erklärt.
Der Default-Mode ist die einfachste Art, den Datensammler process_perfdata.pl
in Nagios zu integrieren. Hierbei wird bei jedem Ereignis ein gesondertes Command process-service-perfdata
ausgeführt.
Grundsätzlich ist in der nagios.cfg
die Verarbeitung der Performancedaten zu aktivieren. Bitte beachten Sie, dass diese Direktive wahrscheinlich bereits in der Konfigurationsdatei enthalten ist (Default ist “0”).
process_performance_data=1
Für jeden Host und jeden Service, für den KEINE Performance-Daten verarbeitet werden sollen, ist die Verarbeitung der Performance-Daten explizit auszuschalten.
define service { ... process_perf_data 0 ... }
Weiterhin ist es ab Nagios 3.x möglich, in der nagios.cfg
das exportieren der Environment-Variablen zu deaktivieren. Diese sind jedoch für den Default-Mode zwingend erforderlich. Daher muss
enable_environment_macros=1
ebenfalls in der nagios.cfg
gesetzt sein.
Zusätzlich wird das Kommando zum Verarbeiten der Performancedaten in der nagios.cfg
angegeben.
service_perfdata_command=process-service-perfdata
Ab Nagios 3.x ist es durchaus sinnvoll, auch die Verarbeitung der Performancedaten für Hosts einzuschalten. Nagios 3 führt durch die geänderte Hostcheck-Logik nun auch die Prüfung der Hosts regelmäßig aus.
host_perfdata_command=process-host-perfdata
Die referenzierten Commands müssen natürlich auch Nagios bekannt gegeben werden. Wie man sieht, sind für den Aufruf von process_perfdata.pl so gut wie keine Optionen nötig. Einzig bei Performancedaten der Host-Checks ist die Option -d ( DATATYPE ) nötig. Wenn Sie die Schnellstart-Installationsanleitungen für Nagios benutzt haben, können Sie die Definitionen in der Datei commands.cfg anpassen.
define command { command_name process-service-perfdata command_line /usr/bin/perl /usr/local/nagios/libexec/process_perfdata.pl } define command { command_name process-host-perfdata command_line /usr/bin/perl /usr/local/nagios/libexec/process_perfdata.pl -d HOSTPERFDATA }
HINWEIS: process_perfdata.pl
kann nicht unter Kontrolle des ePN ( embedded Perl Nagios ) gestartet werden. Daher wird das Script explizit mit /usr/bin/perl
aufgerufen. Wird ePN nicht verwendet oder wird Nagios 3.x verwendet, kann auf die Angabe von /usr/bin/perl
verzichtet werden.
Der Bulk-Mode ist etwas komplizierter als der Default-Mode, reduziert den Load auf dem Nagios Server jedoch merklich, da nun nicht mehr für jeden Service zusätzlich der Datensammler process_perfdata.pl
gestartet werden muss.
Im Bulk-Mode schreibt Nagios die Daten in einem definierten Format in eine temporäre Datei. Diese Datei wiederum wird periodisch von process_perfdata.pl
verarbeitet. Um den Start und den Intervall kümmert sich dabei Nagios selbst.
Auch hier muss die Verarbeitung der Performancedaten in der nagios.cfg
eingeschaltet werden.
process_performance_data=1
Zusätzlich werden einige neue Parameter benötigt.
# # Service Performancedaten # service_perfdata_file=/usr/local/nagios/var/service-perfdata service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$ service_perfdata_file_mode=a service_perfdata_file_processing_interval=15 service_perfdata_file_processing_command=process-service-perfdata-file # # Host Performancedaten ab Nagios 3.x # host_perfdata_file=/usr/local/nagios/var/host-perfdata host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$ host_perfdata_file_mode=a host_perfdata_file_processing_interval=15 host_perfdata_file_processing_command=process-host-perfdata-file
Die Parameter und deren Bedeutung im Einzelnen:
service_perfdata_file
Der Pfad zur temporären Datei, in der die Daten gesammelt werden sollen.service_perfdata_file_template
Das Format der temporären Datei. Hier werden die Daten über Nagios-Macros definiert.service_perfdata_file_mode
Die Option “a” definiert, dass an die Datei angehangen werden soll.service_perfdata_file_processing_interval
Das Intervall beträgt 15 Sekundenservice_perfdata_file_processing_command
das Command, das im definierten Intervall aufgerufen werden soll.Die verwendeten Commands müssen Nagios wiederum bekannt gegeben werden. Wenn Sie die Schnellstart-Installationsanleitungen für Nagios benutzt haben, können Sie die Definitionen in der Datei commands.cfg anpassen.
define command{ command_name process-service-perfdata-file command_line $USER1$/process_perfdata.pl --bulk=/usr/local/nagios/var/service-perfdata } define command{ command_name process-host-perfdata-file command_line $USER1$/process_perfdata.pl --bulk=/usr/local/nagios/var/host-perfdata }
HINWEIS:
process_perfdata.pl
nun mehr Daten zu verarbeiten hat als im Default Mode, kommt es natürlich auch zu längeren Laufzeiten. Daher ist der TIMEOUT Wert in der etc/pnp/process_perfdata.cfg
zu überprüfen und ggf. anzupassen.Die Konfiguration ist identisch mit dem “bulk Mode”, einzig das verwendete Command ist leicht abgewandelt. Wenn Sie die Schnellstart-Installationsanleitungen für Nagios benutzt haben, können Sie die Definitionen in der Datei commands.cfg anpassen.
define command{ command_name process-service-perfdata-file command_line /bin/mv /usr/local/nagios/var/service-perfdata /usr/local/nagios/var/spool/perfdata/service-perfdata.$TIMET$ } define command{ command_name process-host-perfdata-file command_line /bin/mv /usr/local/nagios/var/host-perfdata /usr/local/nagios/var/spool/perfdata/host-perfdata.$TIMET$ }
Durch die Kommandos wird immer nach Ablauf des über service_perfdata_file_processing_interval
eingestellten Intervalls die Datei service-perfdata nach var/spool/ verschoben. Dabei wird das Nagios-Macro $TIMET$ verwendet, an den Dateinamen angehängt, um zu verhindern, dass alte Dateien ungewollt überschrieben werden. Das Macro $TIMET$ enthält den aktuellen Zeitstempel in Unix-Time-Format ( Sekunden seit 1.1.1970 ).
Somit sammeln sich Dateien im Verzeichnis /usr/local/nagios/var/spool/perfdata, die nun mit Hilfe des NPCD verarbeitet werden.
NPCD überwacht das Spool-Verzeichnis und übergibt wiederum alle gefundenen Dateien an process_perfdata.pl
. Damit ist die Verarbeitung der Performancedaten komplett von Nagios entkoppelt. Wir müssen nur noch den NPCD starten.
/usr/local/nagios/bin/npcd -d -f /usr/local/nagios/etc/pnp/npcd.cfg
Die Option -d
veranlasst NPCD im Hintergund als Daemon seinen Dienst zu verrichten.
In der Config-Datei des NPCD, der npcd.cfg
, ist vor dem ersten Start zu prüfen, ob die Pfade zum Spool-Verzeichnis und zu process_perfdata.pl
richtig gesetzt sind.
Weitere Informationen zu NPCD findet Ihr hier.
Wenn alle bis jetzt alles sauber funktioniert hat, kann PNP zum ersten Mal im Browser aufgerufen werden.
Davon ausgehend, dass Nagios unter der URL /nagios
zu erreichen ist, lässt sich PNP nun unter /nagios/pnp/index.php
aufrufen.
Ohne weitere Optionen aufgerufen sucht PNP nach RRD- und XML-Dateien in share/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 Graphen angezeigt werden können.
Während der Installation wurde durch den Aufruf von make install-config
ein Beispiel-Config-File etc/pnp/process_perfdata.cfg-sample
erzeugt. Die Werte in der sample-Datei entsprechen den Default-Werten, die auch in process_perfdata.pl
fest hinterlegt sind, daher ist die process_perfdata.cfg
für den Betrieb nicht zwingend notwendig.
Die Datei process_perfdata.cfg-sample
kann somit als Vorlage für die process_perfdata.cfg
dienen, die immer dann notwendig ist, wenn vom Standard abweichende Werte eingestellt werden sollen.
In der process_perfdata.cfg
lässt sich das Verhalten von process_perfdata.pl
vielfach beeinflussen.
Die wichtigsten Optionen für die Inbetriebnahme sind LOG_LEVEL und LOG_FILE. Im laufenden Betrieb sollte der Log-Level immer auf 0 gesetzt sein, um die Performance von process_perfdata.pl nicht durch unnötiges Schreiben von Logfiles zu beeinträchtigen.
Während der Inbetriebnahme sollte man jedoch den LOG_LEVEL
auf “2” setzen, um zu sehen, was process_perfdata.pl bei der Verarbeitung der Performance-Daten so alles anstellt.
Spätestens bei Support Anfragen im Forum oder auf den Mailinglisten werden wir nach Auszügen aus dem perfdata.log fragen.
Einige grundlegende Einstellungen sind zu prüfen.
1. Sind RRD- und XML-Files erzeugt worden ?
process_perfdata.pl
legt für jeden Host unter share/perfdata ein neues Verzeichnis an. In diesem Verzeichnis wird wiederum für jeden Service eine RRD-Datenbank und ein XML-File erstellt.
Allerdings liefern nicht alle Checks Performance-Daten, das gilt u.a. für “check_ping”, die Alternative “check_icmp” dagegen erzeugt Daten (ab Nagios-Plugin-Version 1.4.12 liefert auch check_ping Performance-Daten).
Die Fehlermeldung “No valid RRD Files found” weist darauf hin, dass das Plugin KEINE Performance-Daten liefert! Teilweise muss man zusätzliche Optionen aktivieren, damit Performance-Daten ausgegeben werden. Evtl. kann das auch durch ein Wrapper-Script geändert werden.
In den Detailinformationen zu jedem Host/Service gibt es das Feld “Performance-Data”. Wenn dort keine Daten stehen, dann werden im jeweiligen Verzeichnis keine Dateien erzeugt und PNP kann deshalb auch keine grafischen Auswertungen liefern!
Das folgende Bild zeigt die Informationen zu einem “PING”-Service. Das blaue Feld enthält den vom Plugin gelieferten Text, das rote die Performance-Daten, die Nagios erkannt hat.
2. Hat Nagios process_perfdata.pl
aufgerufen ?
In der Config-Datei für process_perfdata.pl, der etc/pnp/process_perfdata.cfg
lässt sich der Debug-Level erhöhen. Die Verarbeitung der Daten wird nun in var/perfdata.log
protokolliert.
3. Grafiken werden ohne Text angezeigt ?
siehe Anforderungen
4. verify_pnp_config
Das Perl-Script verify_pnp_config im contrib
-Verzeichnis des Installationsverzeichnisses ermöglicht die Prüfung von Konfigurationseinstellungen und zeigt, ob Performance-Daten vorhanden bzw. gültig sind. Die Syntax dafür ist ziemlich einfach:
./verify_pnp_config -m <Modus>
wobei <Modus>
durch “default”, “bulk” oder “npcd” zu ersetzen ist (ohne Anführungszeichen).
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 kommenden Version 3.0 gibt, wird anschließend auf beide Versionen getrennt eingegangen.
Bis Nagios 2.x erfolgt die Einbindung externer URLs in das Nagios-Web-Interface über die Extended-Info-Objekte. Für PNP verwenden wir die Option action_url, um das PNP-Web-Frontend mit den passenden Optionen aufzurufen.
define serviceextinfo { host_name localhost service_description load action_url /nagios/pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$ }
Wie man sieht, muss für jeden Service zusätzlich eine Extended Info Definition angelegt werden.
Seit Nagios 3.0 ist die Direktive action_url in die Host- bzw. Service-Definition verschoben worden. Die serviceextinfo- und hostextinfo-Definitionen sind entfallen. Damit wird die Definition der URLs zum PNP-Interface wesentlich vereinfacht.
Zuerst definieren wir zwei Nagios-Templates. Falls Sie die Schnellstart-Installationsanleitungen für Nagios benutzt haben, können Sie die folgenden Zeilen der Datei templates.cfg hinzufügen:
define host { name host-pnp register 0 action_url /nagios/pnp/index.php?host=$HOSTNAME$ } define service { name srv-pnp register 0 action_url /nagios/pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$ }
Diese beiden Templates können nun über “use srv-pnp” in der Service-Definition oder “use host-pnp” in der Host-Definition verwendet werden. Wenn Sie die Schnellstart-Installationsanleitungen benutzt haben, können Sie beispielsweise in der Datei localhost.cfg die Definitionen wie folgt erweitern:
define host{ use linux-server,host-pnp ; Name of host templates to use ; This host definition will inherit all variables that are defined ; in (or inherited by) the linux-server host template definition. host_name localhost alias localhost address 127.0.0.1 }
define service{ use local-service,srv-pnp ; Name of service templates to use host_name localhost service_description PING check_command check_ping!100.0,20%!500.0,60% }
Die Links auf die richtigen URLs werden automagisch erstellt.
Ab PNP-0.4.13 ist es möglich, die Graphen bereits in der Statusübersicht beim Überfahren des “Action Url Icons” mit der Maus einzublenden.
Ermöglicht wird dies durch die CGI Includes, welche es uns erlauben, Javascript-Code an geeigneter Stelle im Seitenkopf der Statusübersicht einzubinden ( status.cgi ).
In den PNP-Quellen ist die Datei contrib/ssi/status-header.ssi
bereits enthalten, die verwendeten URLs müssen aber unter Umständen angepasst werden. Wir gehen hier davon aus, dass PNP über /nagios/pnp/index.php
erreichbar ist.
Achtung: ggf. muss auch die URL in der Datei share/pnp/ajax.php angepasst werden.
Die besagte Datei muss nach nagios/share/ssi
kopiert werden, und darf NICHT ausführbar sein. Nagios würde die Datei sonst wirklich wie ein CGI behandeln und ausführen, was aber in diesem Fall zu Fehlern führen würde. Die Apache-Admins mögen bitte “Nagios SSI” nicht “Apache SSI” in Verbindung bringen. Beides hat nichts miteinander zu tun.
Die action_url wird nun um den Aufruf der JavaScript-Funktionen beim Eintreten des Events “onmouseover” erweitert.
define host { name host-pnp register 0 action_url /nagios/pnp/index.php?host=$HOSTNAME$' onmouseover="get_g('$HOSTNAME$','_HOST_')" onmouseout="clear_g()" } define service { name srv-pnp register 0 action_url /nagios/pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$' onmouseover="get_g('$HOSTNAME$','$SERVICEDESC$')" onmouseout="clear_g()" }
Nach einem Restart von Nagios (nach Anpassung der Definitionen) sieht das Ergebnis ungefähr so aus:
Ab PNP-Version 0.4.12 gibt es im contrib-Verzeichnis das Perl-Script verify_pnp_config, 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.17, das ueber http://www.pnp4nagios.org/pnp/dwnld in der aktuellen Developer-Version zu finden ist (ab SVN Rev. 644).
Ältere Versionen haben teilweise weniger Optionen, so dass es in den Beschreibungen der einzelnen Optionen Hinweise auf die PNP-Version gibt.
* Hinweis *: die “langen” Optionen beginnen immer mit zwei ”-”. Leider ist das im Text nicht zu erkennen.
PNP-Version 0.4.12 enthält verify_pnp_config 0.1.2
PNP-Version 0.4.13 enthält verify_pnp_config 0.1.9
PNP-Version 0.4.14 enthält verify_pnp_config 0.1.12
* Achtung * 0.1.9 enthält einen Bug, der für eine Fehlermeldung beim Überprüfen der Template-Definition im Bulk- und NPCD-Modus sorgt. Der letzte Parameter wird als fehlerhaft gemeldet, selbst wenn er korrekt ist. Abhilfe schafft die Anweisung $val .= “\\t”;
vor Zeile 632, so dass die Zeilen wie folgt aussehen:
629 if ($val !~ /([A-Z]+?::[A-Z\$]+?.?)+/) { 630 info ("invTemplate"); 631 } 632 $val .= "\\t"; 633 while ($val =~ s/([A-Z]+?)::(.+?)([^A-Z\$].)//) {
* Achtung * 0.1.12 enthält Bugs bei der Überprüfung von Performance-Daten. Falls diese Funktionalität benötigt wird, sollte die Version aus dem SVN benutzt werden (ab Rev. 633).
0.1.12 enthält einen weiteren Bug, der für eine Fehlermeldung beim Überprüfen der Template-Definition im Bulk- und NPCD-Modus sorgt. SERVICEOUTPUT bzw. HOSTOUTPUT werden als fehlend bemängelt, aber sie gehören nicht in die Template-Definition von PNP, sondern sind lediglich in der Beispielkonfiguration von Nagios enthalten (ab Rev. 639 korrigiert).
Die einfachste Form des Aufrufs zur Überprüfung der Konfiguration lautet:
./verify_pnp_config -m <Modus>
wobei <Modus> durch den benutzen PNP-Modus zu ersetzen ist (default, 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 ("default", "bulk", "NPCD") -l, --logfile=s check configure log file -N, --npcdcfg=s PNP config file for NPCD mode (default: /usr/local/nagios/etc/pnp/npcd.cfg) -P, --ppcfg=s process_perfdata config file (default: /usr/local/nagios/etc/pnp/process_perfdata.cfg) -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/nagios/share/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) -L, --layout=s specify a layout (Nagios2, Nagios3, SuSE, Fedora) -T, --template=s specify the path to the templates directory (default /usr/local/nagios/share/pnp/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) -n, --native show messages in native language (so far "es" or "de") -e, --english show english messages/links -d, --debug some debugging output
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, 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 uebernommen. Ohne ”/” ergibt sich der Pfad aus dem Basisverzeichnis mit angehängtem “bin” und dem Binary-Namen.
(-b / -c ab PNP 0.4.12; -B ab Rev. 612; -U ab Rev. 635, -L ab Rev. 652)
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.
(-m / -l ab PNP 0.4.12, -r ab PNP 0.4.13)
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. (-R ab PNP 0.4.14 bzw. SVN 598; -u / -g ab Rev. 635)
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.
(-p ab PNP 0.4.12)
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:
(-o ab PNP 0.4.12, Berücksichtigung des Semikolons ab PNP 0.4.13)
Im NPCD-Modus kann durch die Option -N
(--npcdcfg
) der Name der Konfigurationsdatei angegeben werden, falls Name oder Ort nicht dem Standard entspricht (NAGIOS_BASE/etc/pnp/npcd.cfg)
(-N ab PNP 0.4.13).
Mit der Option -P
(--ppcfg
) wird der Name der Konfigurationsdatei fuer process_perfdata.pl angegeben, falls Name oder Ort vom Standard abweicht (NAGIOS_BASE/etc/pnp/process_data.cfg)
(-P ab PNP 0.4.13).
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 unterstuetzt. Teilweise muessen auch die Optionen -b, -B und -c benutzt werden. (ab Rev. 640)
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 geprueft. Als Parameter ist der Pfad zum Template-Directory anzugeben. (ab Rev. 655)
Mit der Option -n (--native) gefolgt von “es” or “de” koennen spanische oder deutsche Meldungen gewaehlt werden. (-e ab Rev. 664, PNP 0.4.15)
Die Option -e
(--english
) erzwingt die Anzeige von englischen Meldungen, selbst wenn deutsche Spracheinstellungen erkannt werden.
(-e ab PNP 0.4.13).
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.
(-d ab PNP 0.4.12, -q ab PNP 0.4.13)
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
(ab PNP 0.4.13)
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
Das Verhalten des PNP Webfrontend lässt sich über die Config Datei etc/pnp/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/pnp/config_local.php erfolgen. Sollte die Datei noch nicht existieren, kann die config.php als Vorlage verwendet werden.
Im folgenden die wichtigsten Parameter.
Der Pfad zum RRDtool-Binary. Wird von ./configure
ermittelt.
$conf['rrdtool'] = "/usr/bin/rrdtool";
Höhe und Breite der RRD Graphen.
$conf['graph_width'] = "500"; $conf['graph_height'] = "100";
Zusätzliche Optionen, die bei jedem Aufruf von RRDTool mit übergeben werden. Beispielsweise ----slope-mode
, um die Graphen etwas zu glätten.
$conf['graph_opt'] = "";
Der Pfad zu den von process_perfdata.pl
erstellten RRD- und XML-Dateien.
$conf['rrdbase'] = "/usr/local/nagios/share/perfdata/";
Pfad zu den Config-Files für die Pages.
$conf['page_dir'] = "/usr/local/nagios/etc/pnp/pages/";
Wert in Sekunden, nachdem die PNP-Seiten neu geladen werden sollen.
$conf['refresh'] = "90";
Maximales Alter der RRD-Files in Sekunden. Nach Erreichen dieses Wertes werden Links zu den Graphen als “inactive” gekennzeichnet.
$conf['max_age'] = 60*60*6;
Basis-URL zu den Nagios CGIs.
$conf['nagios_base'] = "/nagios/cgi-bin";
Liste von Usern, für die Links zu den Services des aktuellen Hosts angezeigt werden sollen.
$conf['allowed_for_service_links'] = "EVERYONE";
Liste von Usern, für die das Host-Suchfeld angezeigt werden soll.
$conf['allowed_for_host_search'] = "EVERYONE";
Wird PNP nur mit der Angabe eines Hosts ( index.php?host=<myserver> ) aufgerufen, so wird eine Übersicht aller Services angezeigt, wenn der User in dieser Liste enthalten ist.
$conf['allowed_for_host_overview'] = "EVERYONE";
Das Array $views[] legt fest, welche Zeitspannen die RRD-Graphen dargestellen sollen. Der Titel und die Anzahl der Graphen kann somit hier zentral definiert werden.
$views[0]["title"] = "4 Hours"; $views[0]["start"] = ( 60*60*4 ); $views[1]["title"] = "24 Hours"; $views[1]["start"] = ( 60*60*24 ); $views[2]["title"] = "One Week"; $views[2]["start"] = ( 60*60*24*7 ); $views[3]["title"] = "One Month"; $views[3]["start"] = ( 60*60*24*30 ); $views[4]["title"] = "One Year"; $views[4]["start"] = ( 60*60*24*365 );
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
Das Ende der Zeitbereiche wird über die Option end
definiert.
Beispiel:
http://<Nagios-Host>/nagios/pnp/index.php?host=<hostname>&srv=<servicedesc>&end=-1week
Der Endzeitpunkt der Graphen wird somit, ausgehend vom aktuellen Datum, um eine Woche nach hinten verschoben.
end | view | Ergebnis |
---|---|---|
Alle Ansichten enden mit der aktuellen Zeit | ||
x | Alle Ansichten enden mit dem angegebenen Datum | |
x | Eine Ansicht endet mit der aktuellen Zeit | |
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 |
Bei relativen Zeitangaben (-<n> <Zeitangabe>) endet der Graph basierend auf der aktuellen Zeit, ansonsten um 0:00 Uhr des errechneten Tages.
„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 durch den Konfigurationseintrag „$conf['page_dir']“ angegeben wurde, enthält ein oder mehrere Dateien mit der Endung „.cfg“.
Der Dateiname (ohne die Endung) erscheint in der Liste der verfügbaren Seiten und wird als Titel im Browser angezeigt.
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.
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 }
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} }
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.
Templates werden an zwei Stellen im Dateisystem gespeichert.
* share/pnp/templates.dist - Für Templates, die im PNP Paket bereits enthalten sind.
Soll der Graph für den Service “http” auf Host “localhost” angezeigt werden, so sucht PNP zuerst nach der XML-Datei perfdata/localhost/http.xml
und liest diese ein. Diese XML-Dateien werden automatisch erstellt und enthalten Informationen zum jeweiligen Host und Service. Weiterhin enthält der Kopf Informationen über das Plugin und die Performance-Daten. Im folgenden Beispiel erkennt man anhand des XML-Tags <TEMPLATE>
, welches PNP-Template für diesen Graphen verwendet werden soll.
/localhost/http.xml
<NAGIOS> <DATASOURCE> <TEMPLATE>check_http</TEMPLATE> <DS>1</DS> <NAME>time</NAME> <UNIT>s</UNIT> <ACT>0.006721</ACT> <WARN>1.000000</WARN> <CRIT>2.000000</CRIT> <MIN>0.000000</MIN> <MAX></MAX> </DATASOURCE> <DATASOURCE> <TEMPLATE>check_http</TEMPLATE> <DS>2</DS> <NAME>size</NAME> <UNIT>B</UNIT> <ACT>263</ACT> <WARN></WARN> <CRIT></CRIT> <MIN>0</MIN> <MAX></MAX> </DATASOURCE> ... </NAGIOS>
PNP sucht nun nach einem Template mit dem Namen check_http.php
in folgender Reihenfolge:
Das Template default.php nimmt somit eine Sonderstellung ein und wird immer verwendet, wenn vorher kein anderes Template gefunden wird.
PNP-Templates sind PHP-Dateien, die zur Laufzeit von PNP über die PHP-Funktion include() eingebunden werden. Dies bedeutet, dass jeder PHP-Code in Templates interpretiert wird. Daher ist die Manipulation aller Werte über PHP möglich.
PNP-Templates müssen folgende Eigenschaften besitzen:
Die beiden PHP-Arrays $opt[] und $def[] zusammen bilden den Aufruf von 'rrdtool graph
'. Somit sind alle Optionen möglich, die RRDtool bietet. Die Optionen von RRDtool sind auf der RRDtool Homepage genauestens beschrieben.
Wenn beide Arrays mehrere Datensätze enthalten, so wird für jeden Datensatz ein Graph erstellt.
Weiterhin stehen innerhalb der Templates die Daten aus dem zugehörigen XML-File zur Verfügung, die zum Erstellen der Graphen wieder verwendet werden können.
Am Beispiel des recht einfachen Templates response.php lassen sich die wichtigsten Optionen recht gut beschreiben.
<?php # $opt[1] = "--title \"Response Time For $hostname / $servicedesc\" "; # $def[1] = "DEF:var1=$rrdfile:$DS[1]:AVERAGE " ; $def[1] .= "AREA:var1#00FF00:\"Response Times \" " ; $def[1] .= "LINE1:var1#000000 " ; $def[1] .= "GPRINT:var1:LAST:\"%3.4lg %s$UNIT[1] LAST \" "; $def[1] .= "GPRINT:var1:MAX:\"%3.4lg %s$UNIT[1] MAX \" "; $def[1] .= "GPRINT:var1:AVERAGE:\"%3.4lg %s$UNIT[1] AVERAGE \" "; ?>
$opt[1] = ”--title …”
setzt RRDtool-Optionen für den ersten Datensatz im Array. Hier ist das der Titel des Graphen.
Wie man sieht, werden eingebettete Anführungszeichen durch einen Backslash (\) maskiert.
Die beiden Variablen $hostname
und $servicedesc
sind durch den Aufruf von PNP ermittelt worden und stehen nun auch im Template zur Verfügung.
$def[1] = “DEF:var1=$rrdfile:$DS[1]:AVERAGE ”;
definiert, welche Daten aus welchem RRD-File gelesen werden sollen. $rrdfile enthält den Pfad zur RRD-Datei dieses Services. $DS[1] verweist auf die Datenreihe eins aus der RRD-Datei.
$def[1] .= “AREA:var1#00FF00:\”Response Times \” ”;
durch den Operator ”.=” werden weitere Daten an das Array $def[1] angehangen. Gezeichnet wird eine Fläche (AREA) mit den Daten der Variable var1. Die Farbe wird im HEX-Code #00FF00 definiert. Als Beschriftung wird “Response Times” verwendet.
$def[1] .= “LINE1:var1#000000 ”;
Als Abschluss der eben gezeichneten Fläche wird eine Linie (LINE1) in Schwarz (#000000) gezeichnet.
$def[1] .= “GPRINT:var1:LAST:\”%3.4lg %s$UNIT[1] LAST \” ”;
$def[1] .= “GPRINT:var1:MAX:\”%3.4lg %s$UNIT[1] MAX \” ”;
$def[1] .= “GPRINT:var1:AVERAGE:\”%3.4lg %s$UNIT[1] AVERAGE \” ”;
Die 3 GPRINT Zeilen bilden die Legende des Graphen. Die aktuellen Werte werden dabei über die printf Syntax formatiert.
PNP speichert über den Datensammler process_perfdata.pl
zur Laufzeit nicht nur Performancedaten, sondern auch weitere von Nagios exportierte Werte. Diese Werte werden in der jeweils für den Service gültigen XML-Datei gespeichert.
Im ersten Teil der XML-Datei werden die Performancedaten in ihre Einzelteile zerlegt gespeichert.
<NAGIOS> <DATASOURCE> <TEMPLATE>check_http</TEMPLATE> <DS>1</DS> <NAME>time</NAME> <UNIT>s</UNIT> <ACT>0.006721</ACT> <WARN>1.000000</WARN> <CRIT>2.000000</CRIT> <MIN>0.000000</MIN> <MAX></MAX> </DATASOURCE> ... </NAGIOS>
Das Feld <DS> bezeichnet die DataSource und dient der Identifizierung der Datenreihen innerhalb der RRD-Dateien, ist aber auch der Schlüssel der folgenden Arrays.
Im Array $UNIT[1]
ist somit die Einheit der ersten Datenreihe gespeichert.
Die XML-Datei enthält jedoch noch weitere Informationen. Wird process_perdata.pl im Default-Mode verwendet, so sind alle verfügbaren Makros mit den aktuellen Werten verfügbar. Der folgende Ausschnitt ist jedoch zu Gunsten der Lesbarkeit gekürzt.
<NAGIOS> ... <NAGIOS_SERVICENOTIFICATIONID>8418</NAGIOS_SERVICENOTIFICATIONID> <NAGIOS_SERVICENOTIFICATIONNUMBER>0</NAGIOS_SERVICENOTIFICATIONNUMBER> <NAGIOS_SERVICEOUTPUT>HTTP OK HTTP/1.1 200 OK - 10087 bytes in 0.125 seconds</NAGIOS_SERVICEOUTPUT> <NAGIOS_SERVICEPERCENTCHANGE>0.00</NAGIOS_SERVICEPERCENTCHANGE> <NAGIOS_SERVICEPERFDATA>time=0.124811s;;;0.000000 size=10087B;;;0</NAGIOS_SERVICEPERFDATA> <NAGIOS_SERVICEPERFDATAFILE></NAGIOS_SERVICEPERFDATAFILE> <NAGIOS_SERVICEPROBLEMID>0</NAGIOS_SERVICEPROBLEMID> <NAGIOS_SERVICESTATE>OK</NAGIOS_SERVICESTATE> <NAGIOS_SERVICESTATEID>0</NAGIOS_SERVICESTATEID> <NAGIOS_SERVICESTATETYPE>HARD</NAGIOS_SERVICESTATETYPE> <NAGIOS_SHORTDATETIME>27-12-2007 13:51:23</NAGIOS_SHORTDATETIME> ... </NAGIOS>
Die einzelnen XML-Felder sind als Variablen in den PNP-Templates verwendbar, wobei jedes Feld als Variable gleichen Namens verfügbar ist.
Aus <NAGIOS_SERVICEOUTPUT>
wird die Variable $NAGIOS_SERVICEOUTPUT
.
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.
Notwendig wird dies, wenn allgemeingültige Commands definiert wurden.
Beispiel:
define command { command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -C $ARG1$ -a "$ARG2$" }
Die Folge wäre, dass immer das Template check_nrpe.php verwendet werden würde, auch wenn auf dem zu überwachenden Server via NRPE ein ganz anderes Plugin aufgerufen wurde.
PNP, speziell process_perfdata.pl, sucht zur Laufzeit für jedes check_command im Verzeichnis etc/pnp/check_commands nach einer Config-Datei ( <check_command>.cfg ) und liest diese, wenn vorhanden, ein.
Da unser Beispiel-Command check_nrpe lautet, wird nach etc/pnp/check_commands/check_nrpe.cfg gesucht.
Eine Beispiel-Config wird bereits während der Installation mit der Dateierweiterung .cfg-sample in etc/pnp/check_commands gespeichert.
In diesen Config-Files können zwei Optionen gesetzt werden.
# check_command check_nrpe!load!-w 4,4,4 -c 5,5,5 # ________0__________| | | # ________1__________________| | # ________2__________________________| # CUSTOM_TEMPLATE = 1
CUSTOM_TEMPLATE = 1
sorgt dafür, dass nur der Inhalt von $ARG1$ als Template-Name verwendet wird. Da in diesem Beispiel $ARG1$ mit dem Wert “load” gefüllt ist, ergibt sich als Template-Name “load.php”
CUSTOM_TEMPLATE = 0,1
ergibt → “check_nrpe_load.php”
CUSTOM_TEMPLATE = 1,0
ergibt → “load_check_nrpe.php”
Über die Option “DATATYPE” kann beeinflusst werden mit welchem Datentyp die RRD Datenbank angelegt werden soll. Default ist in diesem Fall “GAUGE”. Für fortlaufende Werte wird aber hier der Datentyp COUNTER benötigt. Normalerweise sollten Plugin Entwickler für Daten von Typ Counter die Einheit “c” verwenden. Dies ist jedoch nicht immer der Fall.
Alle Datenreihen auf Typ COUNTER einstellen.
DATATYPE = COUNTER
Einzelnen Datenreihen spezielle Datentypen zuweisen. (ab PNP-0.4.11)
DATATYPE = GAUGE,GAUGE,COUNTER,COUNTER
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
Weitere Datentypen sind in der RRDTool Dokumentation unter rrdcreate erklärt.
In einigen wenigen Situationen ist es notwendig, die für RRDTool gültigen Daten zu begrenzen.
RRD Datenbanken lassen sich mit definierten Minimum- und Maximum-Werten anlegen. Weitere Infos unter http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
Berücksichtigen des Maximum-Wertes aus den Performance-Daten (ab PNP-0.4.13)
USE_MAX_ON_CREATE = 1
Berücksichtigen des Minimum-Wertes aus den Performance-Daten (ab PNP-0.4.13)
USE_MIN_ON_CREATE = 1
Ist Nagios als verteiltes System implementiert, stellt sich die Frage, wo PNP installiert wird.
Rein technisch ist diese Frage nicht wichtig. PNP kann auf den Slaves sowie auf dem Master Server installiert sein. Oder nur auf dem Master?
Wird PNP auf dem Master betrieben, ist jedoch bei der Übergabe der Daten via send_nsca von den Slave Servern zum Master darauf zu achten, dass auch die Performance-Daten übergeben werden. Weiterhin kommt auf dem Master oft nicht das Original-Check-Command zum Einsatz.
Damit nun aber PNP auf dem Master noch erkennen kann, welches Check-Command auf den Slaves die Daten ermittelt hat, reagiert process_perfdata.pl auf ein zusätzliches Feld am Ende der Performance Daten.
OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;; [check_icmp]
Findet PNP am Ende der Performance Daten einen in eckigen Klammern eingeschlossenen Text, so wird dieser als Check-Command und somit als PNP-Template verwendet.
Die Nagios-Dokumentation zu diesem Thema ist hier zu finden. Das in der Doku verwendete Command ist leicht anzupassen.
Aus
define command{ command_name submit_check_result command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$' }
wird
define command{ command_name submit_check_result command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$ | $SERVICEPERFDATA$ [$SERVICECHECKCOMMAND$]' }
Das Plugin check_multi ist eines der ersten Plugins, das die Funktionen von Nagios 3.0 richtig ausschöpft. Check_Multi ist in der Lage, mehrere Nagios Plugins auszuführen, aber für Nagios als einen Service darzustellen. Die Ausgabe von check_multi erfolgt über mehrere Zeilen, um die Masse an Informationen wieder darstellen zu können.
Daraus ergaben sich jedoch einige Schwierigkeiten für PNP. PNP muss aus den Performance-Daten wieder die Daten der einzelnen Plugins ermitteln können. Zusammen mit Matthias Flacke, dem Entwickler von check_multi, haben wir jedoch recht schnell eine Möglichkeit gefunden, die Daten wieder sauber den einzelnen Plugins zuzuordnen.
In großen Installationen wird man über kurz oder lang feststellen, dass die Verarbeitung der Performancedaten 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.
Mit 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.
Der rrdcached arbeitet als Daemon im Hintergrund und öffnet einen UNIX oder TCP Socket, auf dem er auf Anfragen von rrdtool wartet.
Der rrdcached kennt einige wichtige Optionen, die beim Start übergeben werden.
Option -l definiert den Socket, auf dem der rrdcached Update-Requests annimmt. Der Default-UDP-Port ist 42217
-l unix:/pfad/zum/rrdcached.sock -l 127.0.0.1 -l 127.0.0.1:8888
Option -L ist ein unprivilegierter Socket, der nur den FLUSH-Befehl zum Schreiben der RRD-Datenbanken durch den Daemon auslöst.
-L 127.0.0.1
Option -w bestimmt den Intervall in Sekunden, in dem die Daten auf Disk geschrieben werden sollen.
-w 1800
Option -z definiert einen Delay, der die über die Option -w definierten Schreibzyklen in einen zufälligen Bereich [0-delay] verteilt, um gleichzeitige Schreibzugriffe zu verhindern. Der Wert der Option -z darf nicht größer gewählt werden als -w.
-z 1800
Option -p definiert ein PID File
-p /var/run/rrdcached.pid
Option -j definiert den Pfad zu einem Journal-Verzeichnis. Dort werden alle Aufträge protokolliert und ggf. beim nächsten Start nachgefahren, falls der rrdcached-Daemon abstürzt.
-j /var/cache/rrdcached
Daraus ergibt sich beispielsweise ein Aufruf von rrdached mit folgenden Parametern
rrdcached -w 1800 -z 1800 -p /tmp/rrdcached.pid -j /tmp -l 127.0.0.1
RRDtool selbst wird die Existenz des Daemons über die Option --daemon=<socket> mitgeteilt.
rrdtool --daemon=127.0.0.1 update ...
Dies muss natürlich mit den Startoptionen des rrdcached übereinstimmen!
Da zwei Bestandteile von PNP auf den rrdcached vorbereitet werden müssen, ergeben sich Änderungen in zwei Config-Files.
1. Anpassen der process_perfdata.cfg für den Datensammler process_perfdata.pl
# EXPERIMENTAL rrdcached Support # Use only with rrdtool svn revision 1511+ # RRD_DAEMON_OPTS = 127.0.0.1:8888
2. Anpassen der config_local.php für das Webinterface
# # EXPERIMENTAL rrdcached Support # Use only with rrdtool svn revision 1511+ # # $conf['RRD_DAEMON_OPTS'] = 'unix:/tmp/rrdcached.sock'; $conf['RRD_DAEMON_OPTS'] = '127.0.0.1:8888';
Ab PNP-0.4.11 sind die passenden Optionen bereits in den Beispieldateien enthalten.
NPCD (Nagios-Perfdata-C-Daemon) wurde geschrieben um die asynchrone Bearbeitung von Nagios Performancedaten zu ermöglichen.
In großen Nagios-Installationen kann es zu nicht akzeptierbaren Verspätungen seitens der Checks kommen. Das bedeutet, dass Nagios einen Check zum Zeitpunkt x
ausführen soll, diesen aber erst y
Sekunden später tatsächlich ausführt.
Wenn man dem Nagios Daemon mitteilt, dass man nach jedem einzelnen Check auch die Performancedaten verarbeiten möchte, so geht dies bis zu einem bestimmten Grad gut, ab einer gewissen Anzahl von Checks pro Sekunde allerdings kommt man relativ schnell zu den sog. Latency-Problemen.
Um die Anzahl der Aktionen pro Check zu verringern, kann man nun PNP im Bulk Mode verwenden, wobei die Performancedaten zunächst vom Nagios Prozess gesammelt und anschließend ebenfalls vom Nagios-Prozess selbst verarbeitet werden.
Man kann aber auch dem Nagios-Prozess mitteilen, dass die Verarbeitung der Performancedatendateien lediglich durch das Verschieben der Dateien in ein Spool-Verzeichniss geschehen soll, welches für den Nagios-Prozess selbst eine sehr schnelle Aktion ist und die Performance nicht nennenswert beeinflusst und somit dem Core mehr Zeit für seine eigentliche Arbeit lässt: weitere Checks ausführen, Alamierungen bereitstellen, etc.
Wie bereits erwähnt, ist die Arbeit der Performancedatenverarbeitung durch das schnelle Verschieben der Datei bereits erledigt, aber das bringt die Performancedaten noch nicht in die RRD-Datenbank.
Um den Transport der Performancedatendateien kümmert sich nun der NPCD-Daemon, abseits vom Nagios Prozess, in dem er regelmäßig in das Spool-Verzeichnis guckt und für jede dort gefundene Datei eine Aktion ausführt.
Nachdem NPCD gestartet wurde, erstellt er sich eine Liste von Dateinamen des Spoolverzeichnisses und startet für jede gefundene Datei einen Thread zur weiteren Verarbeitung mittels dem perfdata_file_run_cmd
und dem optionalen perfdata_file_run_cmd_arg
als zusätzliches Argument.
Da das Format der Performancedatendateien dem Format der 'normalen' PNP Bulkmodus Dateien gleicht, kann NPCD nun für jede gefundene Datei also process_perfdata.pl
im Bulk Modus aufrufen.
Pro:
Kontra:
service_perfdata_file_processing_interval
)
NPCD muss zwangsläufig über eine Konfigurationsdatei gesteuert werden. Eine Beispielkonfiguration liegt der PNP-Installation als npcd.cfg-sample
bei.
Nach Umbenennen der -sample
Datei zu npcd.cfg
kann NPCD nun wie folgt gestartet werden:
/usr/local/nagios/bin/npcd -f /usr/local/nagios/etc/pnp/npcd.cfg
oder
/usr/local/nagios/bin/npcd -d -f /usr/local/nagios/etc/pnp/npcd.cfg
um NPCD im Hintergrund als Daemon laufen zu lassen.
Hinweis:
Die -sample
Datei sollte in jedem Fall in npcd.cfg
umbenannt werden, da sie sonst bei einem Update von PNP überschrieben werden könnte.
Dies sind die essentiellen Konfigurationsdirektiven für NPCD:
# Privilege Options user = nagios group = nagios # Logging Options log_type = syslog log_file = /usr/local/nagios/var/npcd.log max_logfile_size = 10485760 log_level=0 # Processing Options perfdata_spool_dir = /usr/local/nagios/var/spool/perfdata/ perfdata_file_run_cmd = /usr/local/nagios/libexec/process_perfdata.pl perfdata_file_run_cmd_args = -b # Thread Options npcd_max_threads=5 # greedy options use_load_threshold = 0 load_threshold = 10.0 # Process Options pid_file=/var/run/npcd.pid
log_type = file
wird diese Logdatei verwendetperfdata_file_run_cmd
angehängt wird<perfdata_file_run_cmd> <perfdata_file_run_cmd_args> <filename_from_perfdata_spool_dir>
use_load_threshold
auf 1 gesetzt ist, werden bei Erreichen dieses load limits keine neuen Threads gestartet