→ Read more...

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...

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.

→ Read more...

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

→ Read more...

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.

→ Read more...

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.

→ Read more...

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:

• Hostname/Servicebeschreibung ⇒ Zeichenkette in Hostname oder Servicebeschreibung
• Hostname; ⇒ Einschränkung auf Hostnamen
• ;Servicebeschreibung ⇒ Einschränkung auf Servicebeschreibung
• Hostname;Servicebeschreibung ⇒ Einschränkung auf Hostname und Servicebeschreibung

(-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)

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.

→ Read more...

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.

Beispiele zur Datumsangabe:

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.

→ Read more...

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...

→ Read more...

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.

→ Read more...

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

→ Read more...