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:
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.
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.
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.
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”.
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.
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
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.
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.
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 |
„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} }
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.
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.
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.
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.
NPCD (Nagios-Perfdata-C-Daemon) wurde geschrieben, um die asynchrone Bearbeitung von Nagios Performance-Daten zu ermöglichen.
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:
Es bleibt Drittanbietern überlassen, aus den Performance-Daten Graphen zu erzeugen.
Quelle: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN201