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 “Sync Mode” ist der einfachste und am leichtesten einzurichten. Nagios ruft für jeden Service (bzw. Host) zusätzlich das Perl-Script process_perfdata.pl auf, um die Daten zu verarbeiten.
Der sync-Mode funktioniert sehr gut bis ca. 1000 Services in einem Intervall von 5 Minuten. Dieser Modus belastet aber auch Nagios am meisten, daher ist es auch in kleinen Installationen ratsam, die weiteren Modi zu beachten.
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 aus Nagios-Sicht die sauberste Art der Verarbeitung. Nagios wird nicht blockiert.
Nagios benutzt wieder eine temporäre Datei, um die Daten zu speichern, und führt nach Ablauf der Zeit wieder ein Command aus. 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.
Achtung Beginnend mit Nagios 4 haben sich die internen Strukturen geändert, so dass der Start des Moduls fehlschlägt. Bisher gibt es keine Pläne Nagios 4 zu unterstützen. Bitte wählen Sie einen der anderen Modi.
In diesem Szenario kommt npcdmod.o, ein NEB-Modul, zum Einsatz.
Diese Modul reduziert die Konfiguration des “Bulk Mode mit NPCD” auf zwei Zeilen in der nagios.cfg.
Dieser Modus ist gleichzusetzen mit dem “Bulk Mode mit NPCD”. Es ist auch genau der gleiche Ablauf und die gleiche Performance.
PNP4Nagios kann seit Version 0.6.12 als Gearman Worker betrieben werden. So sind große verteilte Nagios Umgebungen auf Basis von mod_gearman realisierbar.
Benötigt wird eine fertig eingerichtete mod_gearman Installation wie von Sven Nierlein unter http://labs.consol.de/lang/en/nagios/mod-gearman/ beschrieben.
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.