<liclass="level1"><divclass="li"> Webfrontend basiert auf <ahref="http://www.kohanaphp.com"class="urlextern"title="http://www.kohanaphp.com"rel="nofollow">Kohana</a></div>
</li>
<liclass="level1"><divclass="li"> Webfrontend basiert auf <ahref="http://jqueryui.com/themeroller/"class="urlextern"title="http://jqueryui.com/themeroller/"rel="nofollow">jQuery Themes</a></div>
<liclass="level1"><divclass="li"> Export aus den RRD-Datenbanken im <acronymtitle="Extensible Markup Language">XML</acronym>,CSV und JSON Format über die RRDtool “xport” Funktion.</div>
</li>
<liclass="level1"><divclass="li"> Page-Funktionen neu umgesetzt.</div>
</li>
<liclass="level1"><divclass="li"> Fehlerseiten verweisen auf online <ahref="http://docs.pnp4nagios.org/de/faq"class="urlextern"title="http://docs.pnp4nagios.org/de/faq"rel="nofollow">FAQ-Artikel</a>.</div>
</li>
<liclass="level1"><divclass="li"> Mouseover Popup im Nagios-Frontend über jQuery.clueTip Plugin</div>
</li>
<liclass="level1"><divclass="li"> Volle Unterstützung des rrdcached.</div>
</li>
</ul>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/about#anforderungen"class="wikilink1"title="de:pnp-0.6:about">Anforderungen</a>
<h2><aname="anforderungen_an_plugins"id="anforderungen_an_plugins">Anforderungen an Plugins</a></h2>
<divclass="level2">
<p>
PNP benötigt zwingend gültige Performancedaten von Nagios-Plugins.
</p>
<p>
Was sind also diese Performancedaten?
</p>
<p>
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.
</p>
<p>
<strong>Beispiel check_icmp :</strong>
</p>
<preclass="code"> OK - 127.0.0.1: rta 2.687ms, lost 0% | rta=2.687ms;3000.000;5000.000;0; pl=0%;80;100;;</pre>
<p>
daraus ergibt sich der Output auf der linken Seite des Pipe-Symbols
</p>
<preclass="code"> OK - 127.0.0.1: rta 2.687ms, lost 0%</pre>
festgelegt (einen Auszug davon gibt es <ahref="/de/pnp-0.6/perfdata_format"class="wikilink1"title="de:pnp-0.6:perfdata_format">an dieser Stelle</a>), es soll aber hier noch einmal kurz erläutert werden.
|----|---------|-----|-|----- Einheit ( UOM = UNIT of Measurement )
|---------|-----|-|----- Warning Schwellwert
|-----|-|----- Critical Schwellwert
|-|----- Minimum Wert
|----- Maximum Wert
</pre>
<p>
Mit * gekennzeichnete Werte müssen vorhanden sein. Alle anderen Werte sind optional.
</p>
<p>
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.
<liclass="level1"><divclass="li"><acronymtitle="Practical Extraction and Report Language">Perl</acronym>>= 5.x ohne besondere Module</div>
</li>
<liclass="level1"><divclass="li"> RRDtool ab 1.x; besser 1.2, aber nicht zwingend.<br/>
Achtung: wird RRDtool ohne Paket-Manager installiert, fehlen anschließend möglicherweise die dejavu-Fonts. Das äußert sich z.B. durch fehlende Schriften in den Grafiken</div>
</li>
<liclass="level1"><divclass="li"><acronymtitle="Hypertext Preprocessor">PHP</acronym>>= 5.1.6 für das Webfrontend basierend auf <ahref="http://www.kohanaphp.com"class="urlextern"title="http://www.kohanaphp.com"rel="nofollow">Kohana</a></div>
</li>
<liclass="level1"><divclass="li"> Nagios >= 2.x oder Icinga</div>
</li>
<liclass="level1"><divclass="li"> für Kohana muss außerdem das Modul “mod_rewrite” in der Web-Server-Konfiguration aktiviert sein. Einzelheiten sind in der Web-Server-Dokumentation der entsprechenden Distribution nachzulesen.</div>
</li>
</ul>
</div>
<h2><aname="lizenz"id="lizenz">Lizenz</a></h2>
<divclass="level2">
<p>
PNP ist unter der <ahref="http://www.gnu.de/documents/gpl-2.0.de.html"class="urlextern"title="http://www.gnu.de/documents/gpl-2.0.de.html"rel="nofollow">GPL 2</a> lizensiert.
Die Entwicklung von PNP wird auf <ahref="http://sourceforge.net/projects/pnp4nagios"class="urlextern"title="http://sourceforge.net/projects/pnp4nagios"rel="nofollow">Sourceforge.Net</a> organisiert. PNP ist dort unter dem Projektnamen “PNP4Nagios” registriert.
</p>
<p>
Die jeweils aktuelle (stabile) Version findet ihr im <ahref="http://sourceforge.net/project/showfiles.php?group_id=191615"class="urlextern"title="http://sourceforge.net/project/showfiles.php?group_id=191615"rel="nofollow">Downloadbereich</a>.
</p>
<p>
Wer noch aktueller sein möchte, kann auch die jeweils letzte Entwickler-Version benutzen.
</p>
<p>
Mit der Version 0.6.x wurde von SVN auf GIT zum Verwalten des Sourcecodes gewechselt.
</p>
<p>
Die aktuelle Entwicklung ist jederzeit unter <ahref="https://github.com/lingej/pnp4nagios"class="urlextern"title="https://github.com/lingej/pnp4nagios"rel="nofollow">https://github.com/lingej/pnp4nagios</a> einzusehen. Beim Klicken auf <ahref="http://docs.pnp4nagios.org/_media/dwnld/pnp4nagios-head.tar.gz"class="urlextern"title="http://docs.pnp4nagios.org/_media/dwnld/pnp4nagios-head.tar.gz"rel="nofollow"> pnp4nagios-head.tar.gz</a> wird ein Archiv mit der letzten Version heruntergeladen.
</p>
</div>
<h2><aname="support"id="support">Support</a></h2>
<divclass="level2">
<p>
VOR dem Stellen von Support-Anfragen sollte sichergestellt werden, dass die unter <ahref="http://docs.pnp4nagios.org/de/pnp-0.6/verify"class="urlextern"title="http://docs.pnp4nagios.org/de/pnp-0.6/verify"rel="nofollow">http://docs.pnp4nagios.org/de/pnp-0.6/verify</a> genannten Punkte geprüft wurden.
Die Entwickler und Helfer sind im Monitoring-Portal unter <ahref="http://www.monitoring-portal.org"class="urlextern"title="http://www.monitoring-portal.org"rel="nofollow">http://www.monitoring-portal.org</a> vertreten.
Dort gibt es einen eigenen Bereich zum Thema PNP.<br/>
Bei Support-Anfragen bitte das Betriebssystem und die PNP-Version angeben. Außerdem ist es wichtig, ob PNP aus den Sourcen erstellt oder ein vorgefertigtes Paket verwendet wurde.
</p>
<p>
Erfolgreich gelöste Probleme bitte mit einem [solved] in der Betreffzeile des ersten Beitrags kennzeichnen. Auf diese Weise erleichtern wir anderen Benutzern das Finden von Lösungen zu einem Problem.
</p>
<p>
Weiterhin können die Mailinglisten auf Sourceforge verwendet werden. Dort ist es jedoch üblich, Fragen auf Englisch zu stellen.
</p>
<p>
<ahref="https://lists.sourceforge.net/lists/listinfo/pnp4nagios-users"class="urlextern"title="https://lists.sourceforge.net/lists/listinfo/pnp4nagios-users"rel="nofollow">pnp4nagios-users</a>: Die Users-Liste für allgemeine Fragen zur Konfiguration.
</p>
<p>
<ahref="https://lists.sourceforge.net/lists/listinfo/pnp4nagios-devel"class="urlextern"title="https://lists.sourceforge.net/lists/listinfo/pnp4nagios-devel"rel="nofollow">pnp4nagios-devel</a>: Die Devel-Liste für Anregungen und Fehler Reports.
</p>
<p>
<ahref="https://lists.sourceforge.net/lists/listinfo/pnp4nagios-checkins"class="urlextern"title="https://lists.sourceforge.net/lists/listinfo/pnp4nagios-checkins"rel="nofollow">pnp4nagios-checkins</a>: Auf der Checkins-Liste werden Änderungen im SVN-Repository automatisch veröffentlicht.
Die Performance-Daten werden mit Hilfe von <ahref="http://www.rrdtool.org"class="urlextern"title="http://www.rrdtool.org"rel="nofollow">RRDtool</a> 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.
</p>
<p>
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. Dazu gibt es auch einen <ahref="http://www.linux-magazin.de/Heft-Abo/Ausgaben/2004/06/Daten-ausgesiebt"class="urlextern"title="http://www.linux-magazin.de/Heft-Abo/Ausgaben/2004/06/Daten-ausgesiebt"rel="nofollow">Artikel im Linux-Magazin</a>.
</p>
<p>
Durch die Speicherung in diesem Format ändert sich die Dateigröße nach dem Anlegen nicht mehr. Pro Datenreihe werden ca. 400 KB benötigt.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">Zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/modes"class="wikilink1"title="de:pnp-0.6:modes">PNP-Modi</a>
<h1><aname="die_kunst_daten_zu_sammeln"id="die_kunst_daten_zu_sammeln"href="/de/pnp-0.6/modes"title="Die Kunst Daten zu sammeln">Die Kunst Daten zu sammeln</a></h1>
<divclass="level1">
<p>
PNP unterstützt mehrere Arten, die Performance-Daten zu verarbeiten. Die einzelnen Modi unterscheiden sich durch ihre Komplexität und die zu erwartende Performance.
</p>
<p>
Das folgende Bild zeigt die Verbindungen zwischen Nagios, PNP und RRDtool
</p>
<p>
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 <acronymtitle="Practical Extraction and Report Language">Perl</acronym>-Script übergeben oder in temporäre Dateien geschrieben und später verarbeitet. process_perfdata.pl legt die Datei in <acronymtitle="Extensible Markup Language">XML</acronym>-Dateien ab und speichert sie mit Hilfe von RRDtool in RRD-Dateien.<br/>
</p>
<p>
Bevor Ihr euch auf einen Modus festlegt, lest euch alles durch und entscheidet selbst, welcher Weg für eure Installation der Beste ist.
</p>
</div>
<h1><aname="die_modi_im_vergleich"id="die_modi_im_vergleich">Die Modi im Vergleich</a></h1>
<ahref="/_detail/synchronous.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="synchronous.png"><imgsrc="/_media/synchronous.png?w=150"class="medialeft"align="left"alt=""width="150"/></a>Der “Sync Mode” ist der einfachste und am leichtesten einzurichten. Nagios ruft für jeden Service (bzw. Host) zusätzlich das <acronymtitle="Practical Extraction and Report Language">Perl</acronym>-Script process_perfdata.pl auf, um die Daten zu verarbeiten.
</p>
<p>
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.
<ahref="/_detail/bulk.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="bulk.png"><imgsrc="/_media/bulk.png?w=150"class="medialeft"align="left"alt=""width="150"/></a>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.
</p>
<p>
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.
</p>
<p>
<strong>Hinweis</strong>
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.
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.
</p>
</div>
<h2><aname="bulk_mode_mit_npcd"id="bulk_mode_mit_npcd">Bulk Mode mit NPCD</a></h2>
<divclass="level2">
<p>
<ahref="/_detail/bulk-npcd.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="bulk-npcd.png"><imgsrc="/_media/bulk-npcd.png?w=150"class="medialeft"align="left"alt=""width="150"/></a>Dies ist aus Nagios-Sicht die sauberste Art der Verarbeitung. Nagios wird nicht blockiert.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
<h2><aname="bulk_mode_mit_npcdmod"id="bulk_mode_mit_npcdmod">Bulk Mode mit npcdmod</a></h2>
<divclass="level2">
<p>
<strong>Achtung</strong>
<em>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.</em>
</p>
<p>
<ahref="/_detail/bulk-npcdmod.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="bulk-npcdmod.png"><imgsrc="/_media/bulk-npcdmod.png?w=150"class="medialeft"align="left"alt=""width="150"/></a>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.
</p>
<p>
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.
</p>
<p>
Benötigt wird eine fertig eingerichtete mod_gearman Installation wie von Sven Nierlein unter <ahref="http://labs.consol.de/lang/en/nagios/mod-gearman/"class="urlextern"title="http://labs.consol.de/lang/en/nagios/mod-gearman/"rel="nofollow">http://labs.consol.de/lang/en/nagios/mod-gearman/</a> beschrieben.
Welchen der beschriebenen Wege ihr verwendet, hängt also stark von der Größe der Nagios-Installation ab.
</p>
<p>
Die verwendeten Begriffe werden euch aber in der Dokumentation immer wieder über den Weg laufen.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">Zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/install"class="wikilink1"title="de:pnp-0.6:install">Installation</a>
<h1><aname="upgrade_auf_version_06x"id="upgrade_auf_version_06x"href="/de/pnp-0.6/upgrade"title="Upgrade auf Version 0.6.x">Upgrade auf Version 0.6.x</a></h1>
<divclass="level1">
<p>
Das Web-Frontend ist komplett neu geschrieben worden und basiert nun auf dem <acronymtitle="Hypertext Preprocessor">PHP</acronym> MVC Framework <ahref="http://www.kohanaphp.com"class="urlextern"title="http://www.kohanaphp.com"rel="nofollow">Kohana</a>. Somit ergeben sich grundlegend andere Abhängigkeiten, die dringend vor der Installation geprüft werden müssen.
</p>
<p>
Anmerkung: Ein Upgrade läuft zuerst wie eine Neuinstallation. Anschließend sind einige Anpassungen durchzuführen, die weiter unten beschrieben sind.
</p>
<p>
PNP 0.4.x wurde ohne weitere Angabe von Optionen beim Aufruf von <code>./configure</code> unterhalb einer Nagios-Installation unter <code>/usr/local/nagios</code> installiert.
</p>
<p>
PNP 0.6.x wird bei Angabe keiner weiteren Optionen unter <code>/usr/local/pnp4nagios</code> installiert, ist also wie Nagios als eigenständige Applikation zu sehen.
</p>
<p>
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.
</p>
</div>
<h2><aname="vergleich_der_struktur"id="vergleich_der_struktur">Vergleich der Struktur</a></h2>
<divclass="level2">
<p>
Summary einer Installation von PNP 0.4.14
</p>
<preclass="code">
./configure
...
*** Configuration summary for pnp 0.4.14 05-02-2009 ***
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
Location of rrdtool binary: /usr/bin/rrdtool Version 1.3.1
Die Vorlagen der action_url-Definitionen haben sich verändert. Statt ”/nagios/pnp” ist ”/pnp4nagios” einzutragen und statt “index.php” wird nun “graph” benutzt
<strong>Achtung</strong>: Es ist <em>kein</em> Fehler, dass die Zeichenketten vor und nach “class” jeweils nur ein Apostroph enthalten.
</p>
<p>
Anders als in der 0.4.x Dokumentation vermerkt gelten die Templates für Nagios 2.x und 3.x. Der einzige Unterschied besteht darin, dass die action_url-Direktive in Nagios 2.x nicht in der Service-Definition, sondern in eigenen serviceextinfo-Definitionen verfügbar ist.
</p>
<p>
Innerhalb der <acronymtitle="Hypertext Preprocessor">PHP</acronym>-Dateien im templates-Verzeichnis müssen alle Variablen vor der ersten Benutzung initialisiert werden, z.B.
</p>
<preclass="code">$lower = ""</pre>
<p>
Das gilt auch für Variablen, an die früher “angehängt” werden konnte, ohne sie vorher zu initialisieren. Daher wird aus
<liclass="level1"><divclass="li"><code>/usr/local/nagios/share/perfdata</code> nach <code>/usr/local/pnp4nagios/var/perfdata</code> kopieren. Achtung: Auf Permissions achten.</div>
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.<br/>
<strong>Achtung:</strong> Die Beschreibung bezieht sich auf die Developer-Version PNP 0.6.0.<br/>
Bitte vergessen Sie nicht, dass PNP nach der Installation noch konfiguriert werden muss.
</p>
</div>
<h2><aname="make_und_co"id="make_und_co">Make und Co</a></h2>
<divclass="level2">
<p>
Die Installation von PNP wird wie bei Nagios auch über <ahref="http://de.wikipedia.org/wiki/Makefile"class="interwiki iw_wpde"title="http://de.wikipedia.org/wiki/Makefile">Makefile</a>s gesteuert. Dabei wird durch den Aufruf von ./configure das System analysiert und die ermittelten Werte in Makefiles übernommen.
</p>
<p>
Als User root wird PNP in /usr/local/src entpackt.
</p>
<preclass="code">
tar -xvzf pnp4nagios-HEAD.tar.gz
cd pnp4nagios
</pre>
<p>
Im Verzeichnis pnp4nagios wird nun ./configure aufgerufen.
</p>
<preclass="code">
./configure
</pre>
<p>
<strong>Hinweis:</strong> Ohne weitere Optionen werden als Benutzer und Gruppe “nagios” verwendet. Bei abweichenden Werten sind die Parameter ”--with-nagios-user” und ”--with-nagios-group” zu benutzen. Im Falle von Icinga könnte der Aufruf so aussehen
Review the options above for accuracy. If they look okay,
type 'make all' to compile.</pre>
<p>
Die angezeigten Pfade sollten nun geprüft werden. Falls die gezeigten Werte nicht passen, kann durch einen erneuten Aufruf von ./configure mit den passenden Optionen Abhilfe geschaffen werden.<br/>
<strong>ACHTUNG:</strong> Nachdem es immer wieder Schwierigkeiten gibt: “Location of rrdtool binary” bedeutet inkl. Namen des Binary! Bei Bedarf kann man das beim ./configure als Parameter angeben:
kompiliert nun die in C geschriebenen Komponenten wie NPCD
</p>
<preclass="code">make install</pre>
<p>
kopiert alles an die richtige Stelle im Filesystem. Die Pfade wurden ja beim ./configure bereits gezeigt.
</p>
<p>
Nach der Installation der Programm- und <acronymtitle="HyperText Markup Language">HTML</acronym>-Dateien wird mit
</p>
<preclass="code">make install-webconf</pre>
<p>
eine Konfigurationsdatei in das Konfigurationsverzeichnis des Apache-Web-Servers kopiert.
</p>
<p>
Optional kann noch
</p>
<preclass="code">make install-config</pre>
<p>
aufgerufen werden. Damit werden Config-Files für process_perfdata.pl und npcd nach etc/pnp kopiert.
</p>
<p>
Wird das INIT Script für den NPCD benötigt, so sorgt
</p>
<preclass="code">make install-init</pre>
<p>
für die Installation nach /etc/init.d
</p>
<p>
Zusammenfassen lassen sich diese einzelnen Commands durch
</p>
<preclass="code">make fullinstall</pre>
<p>
<strong>Hinweis:</strong> Wie oben schon beschrieben wird standardmässig mit den Nagios-Einstellungen installiert. Wird Icinga genutzt, muss in der Datei ”/etc/apache2/conf.d/pnp4nagios.conf” der Pfad zum AuthUserFile angepasst werden (Pfad evtl. je nach Distri anpassen):
<strong>Achtung:</strong> Nach dem Kopieren der Konfigurationsdatei für den Web-Server bzw. Ändern des AuthUserFile ist ein Restart des Web-Servers notwendig (<code>service httpd restart</code> bzw. <code>/etc/init.d/apache2 restart</code>).
</p>
</div>
<h2><aname="update"id="update">Update</a></h2>
<divclass="level2">
<p>
Das Update einer 0.6.x-Version funktioniert (fast) 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 <code>share/templates.dist</code> vorgenommen haben. Eigene Templates sollten im Ordner <code>share/templates</code> abgelegt werden.<br/>
<strong>Achtung</strong>: Wenn Sie in der Datei config.php Änderungen vorgenommen haben, sollten Sie diese Datei sichern, bevor sie bei einem “make install-config” überschrieben wird.
</p>
<p>
Sie können die Schritte <code>make install-webconf</code> und <code>make install-init</code>überspringen, denn zwischen den 0.6.x-Versionen gab es an dieser Stelle keine Änderungen.
Beispiel-Config-Files mit der Dateierweiterung <code>-sample</code> in
</p>
<preclass="code"> /usr/local/pnp4nagios/etc</pre>
<p>
Die Config-Datei config.php für das Web-Frontend in
</p>
<preclass="code"> /usr/local/pnp4nagios/etc</pre>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">Zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/config"class="wikilink1"title="de:pnp-0.6:config">Konfiguration</a>
Im Folgenden wird die Konfiguration der bereits erwähnten <ahref="/de/pnp-0.6/modes"class="wikilink1"title="de:pnp-0.6:modes">Arten der Performance-Daten Verarbeitung</a> genauer erklärt.
</p>
<p>
Die bevorzugte Methode der PNP-Entwickler ist der “Bulk Mode mit NPCD und npcdmod”.
<ahref="/_detail/synchronous.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="synchronous.png"><imgsrc="/_media/synchronous.png?w=150"class="mediaright"align="right"alt=""width="150"/></a>Der Synchronous-Mode ist die einfachste Art, den Datensammler <code>process_perfdata.pl</code> in Nagios zu integrieren. Hierbei wird bei jedem Ereignis ein gesondertes Command <code>process-service-perfdata</code> (bzw. <code>process-host-perfdata</code>) ausgeführt.
</p>
<p>
Grundsätzlich ist in der <code>nagios.cfg</code> die Verarbeitung der Performance-Daten zu aktivieren. Bitte beachten Sie, dass diese Direktive wahrscheinlich bereits in der Konfigurationsdatei enthalten ist (Default ist “0”).
Für jeden Host und jeden Service, für den KEINE Performance-Daten verarbeitet werden sollen, ist die Verarbeitung der Performance-Daten explizit auszuschalten.
</p>
<preclass="code">
define service {
...
process_perf_data 0
...
}
</pre>
<p>
Weiterhin ist es ab Nagios 3.x möglich, in der <code>nagios.cfg</code> das Exportieren der Environment-Variablen zu deaktivieren. Diese sind jedoch für den Synchronous-Mode zwingend erforderlich. Daher muss
Ab Nagios 3.x ist es durchaus sinnvoll, auch die Verarbeitung der Performance-Daten für Hosts einzuschalten. Nagios 3 führt durch die geänderte Hostcheck-Logik nun auch die Prüfung der Hosts regelmäßig aus.
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 Performance-Daten der Host-Checks ist die Option -d ( DATATYPE ) nötig. Wenn Sie die <ahref="http://www.nagios-wiki.de/nagios/doku3/quickstart"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/quickstart"rel="nofollow">Schnellstart-Installationsanleitungen</a> für Nagios benutzt haben, können Sie die Definitionen in der Datei commands.cfg anpassen.
<strong>HINWEIS:</strong><code>process_perfdata.pl</code> kann nicht unter Kontrolle des ePN ( embedded <acronymtitle="Practical Extraction and Report Language">Perl</acronym> Nagios ) gestartet werden. Daher wird das Script explizit mit <code>/usr/bin/perl</code> aufgerufen. Wird ePN nicht verwendet oder wird Nagios 3.x verwendet, kann auf die Angabe von <code>/usr/bin/perl</code> verzichtet werden.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/verify"class="wikilink1"title="de:pnp-0.6:verify">Funktion prüfen</a>
<ahref="/_detail/bulk.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="bulk.png"><imgsrc="/_media/bulk.png?w=150"class="mediaright"align="right"alt=""width="150"/></a>Der Bulk-Mode ist etwas komplizierter als der Synchronous-Mode, reduziert die Last auf dem Nagios Server jedoch merklich, da nun nicht mehr für jeden Service bzw. Host zusätzlich der Datensammler <code>process_perfdata.pl</code> gestartet werden muss.
</p>
<p>
Im Bulk-Mode schreibt Nagios die Daten in einem definierten Format in eine temporäre Datei. Diese Datei wiederum wird periodisch von <code>process_perfdata.pl</code> verarbeitet. Um den Start und den Intervall kümmert sich dabei Nagios selbst.
</p>
<p>
Auch hier muss die Verarbeitung der Performance-Daten in der <code>nagios.cfg</code> eingeschaltet werden.
<strong>Achtung:</strong> Die Template-Definitionen weichen von denen in der Original-nagios.cfg ab!
</p>
<p>
Die Parameter und deren Bedeutung im Einzelnen:
</p>
<ul>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file</strong></code> Der Pfad zur temporären Datei, in der die Daten gesammelt werden sollen.</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_template</strong></code> Das Format der temporären Datei. Hier werden die Daten über Nagios-Macros definiert.</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_mode</strong></code> Die Option “a” definiert, dass an die Datei angehangen werden soll.</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_processing_interval</strong></code> Das Intervall beträgt 15 Sekunden</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_processing_command</strong></code> das Command, das im definierten Intervall aufgerufen werden soll.</div>
</li>
</ul>
<p>
Die verwendeten Commands müssen Nagios wiederum bekannt gegeben werden. Wenn Sie die <ahref="http://www.nagios-wiki.de/nagios/doku3/quickstart"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/quickstart"rel="nofollow">Schnellstart-Installationsanleitungen</a> für Nagios benutzt haben, können Sie die Definitionen in der Datei commands.cfg anpassen.
<divclass='box_content'> Da <code>process_perfdata.pl</code> 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 <code>etc/process_perfdata.cfg</code> zu überprüfen und ggf. anzupassen.</div>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/verify"class="wikilink1"title="de:pnp-0.6:verify">Funktion prüfen</a>
</p>
</div>
<h2><aname="bulk_mode_with_npcd"id="bulk_mode_with_npcd">Bulk Mode with NPCD</a></h2>
<divclass="level2">
<p>
<ahref="/_detail/bulk-npcd.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="bulk-npcd.png"><imgsrc="/_media/bulk-npcd.png?w=150"class="mediaright"align="right"alt=""width="150"/></a>Die Konfiguration ist identisch mit dem “Bulk Mode”, einzig das verwendete Command ist leicht abgewandelt.
</p>
<p>
Auch hier muss die Verarbeitung der Performance-Daten in der <code>nagios.cfg</code> eingeschaltet werden.
<strong>Achtung:</strong> Die Template-Definitionen weichen von denen in der Original-nagios.cfg ab!
</p>
<p>
Die Parameter und deren Bedeutung im Einzelnen:
</p>
<ul>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file</strong></code> Der Pfad zur temporären Datei, in der die Daten gesammelt werden sollen.</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_template</strong></code> Das Format der temporären Datei. Hier werden die Daten über Nagios-Macros definiert.</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_mode</strong></code> Die Option “a” definiert, dass an die Datei angehangen werden soll.</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_processing_interval</strong></code> Das Intervall beträgt 15 Sekunden</div>
</li>
<liclass="level1"><divclass="li"><code><strong>service_perfdata_file_processing_command</strong></code> das Command, das im definierten Intervall aufgerufen werden soll.</div>
</li>
</ul>
<p>
Die verwendeten Commands müssen Nagios wiederum bekannt gegeben werden. Wenn Sie die <ahref="http://www.nagios-wiki.de/nagios/doku3/quickstart"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/quickstart"rel="nofollow">Schnellstart-Installationsanleitungen</a> für Nagios benutzt haben, können Sie die Definitionen in der Datei commands.cfg anpassen.
Durch die Kommandos wird immer nach Ablauf des über <code><strong>service_perfdata_file_processing_interval</strong></code> 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 ).
</p>
<p>
Somit sammeln sich Dateien im Verzeichnis /usr/local/pnp4nagios/var/spool/, die nun mit Hilfe des NPCD verarbeitet werden.
</p>
<p>
NPCD überwacht das Spool-Verzeichnis und übergibt wiederum alle gefundenen Dateien an <code>process_perfdata.pl</code>. Damit ist die Verarbeitung der Performancedaten komplett von Nagios entkoppelt. Wir müssen nur noch den NPCD starten.
Die Option <code>-d</code> veranlasst NPCD im Hintergund als Daemon seinen Dienst zu verrichten.
</p>
<p>
Das Init Script für den NPCD wir während der Installation über “make install-init” installiert und kann somit auch für den Start verwendet werden.
</p>
<preclass="code"> /etc/init.d/npcd start</pre>
<p>
In der Config-Datei des NPCD, der <code>npcd.cfg</code>, ist vor dem ersten Start zu prüfen, ob die Pfade zum Spool-Verzeichnis und zu <code>process_perfdata.pl</code> richtig gesetzt sind.
</p>
<p>
Weitere Informationen zu NPCD findet ihr <ahref="/de/pnp-0.6/npcd"class="wikilink1"title="de:pnp-0.6:npcd">hier</a>.
</p>
</div>
<h2><aname="bulk_mode_with_npcd_und_npcdmod"id="bulk_mode_with_npcd_und_npcdmod">Bulk Mode with NPCD und npcdmod</a></h2>
<divclass="level2">
<p>
<strong>Achtung</strong>
<em>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.</em>
</p>
<p>
<ahref="/_detail/bulk-npcdmod.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="bulk-npcdmod.png"><imgsrc="/_media/bulk-npcdmod.png?w=150"class="mediaright"align="right"alt=""width="150"/></a> Bei diesem Modus kommt das Eventbroker-Modul npcdmod.o zu Einsatz. Der Datenfluss ist jedoch identisch zum “Bulk Mode mit NPCD”. Die internen Perfdata-Routinen von Nagios, die über die “*_perf_data_*” Optionen in der <code>nagios.cfg</code> konfiguriert werden, kommen <strong>NICHT</strong> mehr zu Einsatz. Das Modul npcdmod.o kümmert sich um die für PNP nötige Aufbereitung der Daten.
</p>
<p>
Vorteil:
</p>
<ul>
<liclass="level1"><divclass="li"> Die Perfdata-Routinen innerhalb von Nagios stehen wieder für andere Addons zur Verfügung.</div>
</li>
<liclass="level1"><divclass="li"> Die Konfiguration reduziert sich.</div>
</li>
<liclass="level1"><divclass="li"> Die bevorzugte Methode der PNP-Entwickler.</div>
Alle anderen auf dieser Seite gezeigten Optionen dürfen für diesen Modus <strong>NICHT</strong> mehr verwendet werden.
</p>
<p>
<strong>Achtung:</strong> Wichtig sind in diesem Zusammenhang auch die <code>event_broker_options</code> bei einem von -1 abweichenden Wert. Für PNP müssen die Bits 2 und 3 gesetzt sein (0b01100; siehe auch <ahref="http://www.nagios-wiki.de/nagios/ndo/eventbroker_optionen"class="urlextern"title="http://www.nagios-wiki.de/nagios/ndo/eventbroker_optionen"rel="nofollow">http://www.nagios-wiki.de/nagios/ndo/eventbroker_optionen</a>).
</p>
<p>
Nach dem Neustart von Nagios werden Informationen zum Ladevorgang des Moduls protokolliert.
</p>
<p>
Auszug aus den nagios.log
</p>
<preclass="code">
[1277545053] npcdmod: Copyright (c) 2008-2009 Hendrik Baecker (andurin@process-zero.de) - http://www.pnp4nagios.org
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. Außerdem kann man dadurch Nagios und PNP4Nagios auf unterschiedliche Rechner verteilen.
</p>
<p>
Benötigt wird eine fertig eingerichtete mod_gearman Installation wie von Sven Nierlein unter <ahref="http://labs.consol.de/lang/en/nagios/mod-gearman/"class="urlextern"title="http://labs.consol.de/lang/en/nagios/mod-gearman/"rel="nofollow">http://labs.consol.de/lang/en/nagios/mod-gearman/</a> beschrieben.
</p>
<p>
In <code>etc/process_perfdata.cfg</code> gibt es einen gearman-Abschnitt:
</p>
<preclass="code"> PREFORK = 1
GEARMAN_HOST = localhost:4730
REQUESTS_PER_CHILD = 10000
ENCRYPTION = 1
KEY = should_be_changed
#KEY_FILE = /usr/local/pnp4nagios/etc/secret.key
</pre>
<p>
Dort ist mit <code>PREFORK = <n></code> die Anzahl der zu startenden Kindprozessen anzugeben.
</p>
<p>
<code>GEARMAN_HOST = <host>:<port></code> definiert Rechner und Port, auf dem der gearman-Daemon die Daten bereitstellt.
Über <code>REQUESTS_PER_CHILD = <n></code> kann die maximal zu verarbeitende Anzahl von Anforderungen pro Prozess eingestellt werden.
</p>
<p>
<code>ENCRYPTION = <1|0></code> stellt ein, ob Verschlüsselung benutzt werden soll. Die Standardeinstellung ist eine aktivierte Verschlüsselung (“1”) und das sollte nur in Ausnahmefällen verändert werden.
Dabei kann entweder über <code>KEY = <Schlüssel></code> der zu benutzende Schlüssel definiert oder per <code>KEY_FILE = <Schlüsseldatei></code> der Standort einer Schlüsseldatei angegeben werden.
</p>
<p>
<code>/etc/init.d/pnp_gearman_worker</code> enthält Verweise auf die <acronymtitle="Practical Extraction and Report Language">Perl</acronym>-Prozedur <code>process_perfdata.pl</code> sowie die Konfigurationsdatei <code>process_perfdata.cfg</code>.
<h1><aname="pruefen_der_installation"id="pruefen_der_installation"href="/de/pnp-0.6/verify"title="Prüfen der Installation">Prüfen der Installation</a></h1>
<divclass="level1">
<p>
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 <ahref="http://%3CServername%3E/pnp4nagios/"class="urlextern"title="http://<Servername>/pnp4nagios/"rel="nofollow">http://<Servername>/pnp4nagios/</a>.
</p>
<p>
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.<br/>
</p>
<p>
Sind alle Tests erfolgreich verlaufen, so kann die Datei <code>pnp4nagios/share/install.php</code> gelöscht oder umbenannt werden. Erst dann ist das Webinterface erreichbar.
</p>
<p>
Alternativ kann eine Datei <code>pnp4nagios/share/install.ignore</code> angelegt werden, um den Aufruf des Installers nach weiteren Updates zu ignorieren.
</p>
<p>
Ohne weitere Optionen sucht PNP nach RRD- und <acronymtitle="Extensible Markup Language">XML</acronym>-Dateien in <code>pnp4nagios/var/perfdata/</code> und zeigt alle Graphen des ersten Hosts in der Übersicht an.
</p>
<p>
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.
</p>
</div>
<h2><aname="logfile"id="logfile">Logfile</a></h2>
<divclass="level2">
<p>
Während der Installation wurde durch den Aufruf von <code>make install-config</code> ein Beispiel-Config-File <code>etc/process_perfdata.cfg-sample</code> erzeugt. Die Werte in der sample-Datei entsprechen den Default-Werten, die auch in <code>process_perfdata.pl</code> fest hinterlegt sind, daher ist die <code>process_perfdata.cfg</code> für den Betrieb nicht zwingend notwendig.
</p>
<p>
Die Datei <code>process_perfdata.cfg-sample</code> kann somit als Vorlage für die <code>process_perfdata.cfg</code> dienen, die immer dann notwendig ist, wenn vom Standard abweichende Werte eingestellt werden sollen.
</p>
<p>
In der <code>process_perfdata.<strong>cfg</strong></code> lässt sich das Verhalten von <code>process_perfdata.pl</code> vielfach beeinflussen.
</p>
<p>
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.
</p>
<p>
Während der Inbetriebnahme sollte man jedoch den <code>LOG_LEVEL</code> auf “2” setzen, um zu sehen, was process_perfdata.pl bei der Verarbeitung der Performance-Daten so alles anstellt.
</p>
<p>
Spätestens bei <ahref="/de/pnp-0.6/about#support"class="wikilink1"title="de:pnp-0.6:about">Support Anfragen</a> im Forum oder auf den Mailinglisten werden wir sowohl nach Auszügen aus dem perfdata.log als auch nach der Ausgabe des <ahref="/de/pnp-0.6/verify_pnp_config"class="wikilink1"title="de:pnp-0.6:verify_pnp_config">verify_pnp_config-Scripts</a> fragen. Es empfiehlt sich also, diese Angaben gleich mitzuliefern <imgsrc="/lib/images/smileys/icon_wink.gif"class="middle"alt=";-)"/>.
</p>
</div>
<h2><aname="was_aber_wenn_nicht"id="was_aber_wenn_nicht">Was aber wenn nicht ?</a></h2>
<divclass="level2">
<p>
Einige grundlegende Einstellungen sind zu prüfen.
</p>
<p>
1. Sind RRD- und <acronymtitle="Extensible Markup Language">XML</acronym>-Files erzeugt worden ?
</p>
<p>
<code>process_perfdata.pl</code> legt für jeden Host unter var/perfdata ein neues Verzeichnis an. In diesem Verzeichnis wird wiederum für jeden Service eine RRD-Datenbank und ein <acronymtitle="Extensible Markup Language">XML</acronym>-File erstellt. Für den Host-Check lautet der Dateinamen <code>_HOST_.xml</code> bzw. <code>_HOST_.rrd</code>.<br/>
Falls Graphen urplötzlich nicht mehr weitergeführt werden, dann hilft vielleicht ein Blick in die betroffene <acronymtitle="Extensible Markup Language">XML</acronym>-Datei. Dort gibt es u.a. die Tags <RC> und <TXT>. <RC> zeigt den Return-Code des RRDtool-Updates der RRD-Datei, <TXT> eine textuelle Beschreibung.<br/>
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).<br/>
Teilweise muss man zusätzliche Optionen aktivieren, damit Performance-Daten ausgegeben werden. Evtl. kann das auch durch ein <ahref="/de/pnp-0.6/wrapper"class="wikilink1"title="de:pnp-0.6:wrapper">Wrapper-Script</a> geändert werden.<br/>
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!<br/>
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.<br/>
<ahref="/_detail/srv_info.png?id=de%3Apnp-0.6%3Adoc_complete"class="media"title="srv_info.png"><imgsrc="/_media/srv_info.png?w=250"class="media"title="Informationen zu "PING""alt="Informationen zu "PING""width="250"/></a>
</p>
<p>
2. Hat Nagios <code>process_perfdata.pl</code> aufgerufen ?
</p>
<p>
In der Config-Datei für process_perfdata.pl, der <code>etc/process_perfdata.<strong>cfg</strong></code> lässt sich der Debug-Level erhöhen. Die Verarbeitung der Daten wird nun in <code>var/perfdata.log</code> bzw. im Syslog protokolliert.
4. Einige Graphen werden angezeigt, andere melden den Fehler <code>“parser error: Input is not proper UTF-8”</code> oder etwas ähnliches. Bitte prüfen Sie, ob die Daten “spezielle” Zeichen enthalten, die nicht im <acronymtitle="American Standard Code for Information Interchange">ASCII</acronym>-Zeichensatz vorhanden sind (Umlaute, etc). Versuchen Sie, in <code>process_perfdata.cfg</code> den Wert von <code><acronymtitle="Extensible Markup Language">XML</acronym>_ENC</code> auf <code><acronymtitle="International Organization for Standardization">ISO</acronym>-8859-1</code> oder einen anderen passenden Wert zu setzen. Warten Sie, bis die xml-Datei neu erzeugt wurde und probieren Sie es nochmal.
</p>
<p>
5. Bei aktiviertem npcdmod-Modul muss der Wert von <code>event_broker_options</code> in der nagios.cfg ggf. angepasst werden. Hinweise gibt es <ahref="/de/pnp-0.6/config#bulk_mode_with_npcd_und_npcdmod"class="wikilink1"title="de:pnp-0.6:config">hier</a>.
</p>
<p>
6. verify_pnp_config
Das <acronymtitle="Practical Extraction and Report Language">Perl</acronym>-Script <ahref="/de/pnp-0.6/verify_pnp_config"class="wikilink1"title="de:pnp-0.6:verify_pnp_config">verify_pnp_config.pl</a> ermöglicht die Prüfung von Konfigurationseinstellungen und zeigt, ob Performance-Daten vorhanden sind.
</p>
<p>
7. Es scheint zu funktionieren, aber es bleiben einige Dateien Spool-Verzeichnis stehen (/usr/local/pnp4nagios/var/spool/<perfdata_filename>-PID-<process_perfdata_pid>). Wenn <code>process_perdata.pl</code> nicht in das Zielverzeichnis (/usr/local/pnp4nagios/share/perfdata/<host>) schreiben kann, wird es anhalten und die Quelldatei nicht löschen. Das erhöht die Größe des Spool-Verzeichnisses und die Verarbeitung der Performance-Daten verlangsamen. Dieses Problem kann auftreten, wenn Sie Verzeichnisse aus einer vorherigen Installation kopiert und/oder manuell Verzeichnisse angelegt haben und dabei die falschen Benutzer/Berechtigungen verwendet haben.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/verify_pnp_config"class="wikilink1"title="de:pnp-0.6:verify_pnp_config">verify_pnp_config.pl</a>
Bei Problemen kann das <acronymtitle="Practical Extraction and Report Language">Perl</acronym>-Script <code>verify_pnp_config</code> von <ahref="http://verify.pnp4nagios.org"class="urlextern"title="http://verify.pnp4nagios.org"rel="nofollow">http://verify.pnp4nagios.org</a> helfen die aktuelle Nagios Konfiguration zu prüfen und entsprechend Hinweise zur Lösung liefern.
Bei <ahref="/de/pnp-0.6/about#support"class="wikilink1"title="de:pnp-0.6:about">Support Anfragen</a> sollte immer die Ausgabe dieses Scripts mit angegeben werden, da die Entwickler sich so einen besseren Überblick über das verwendete System machen können.
Das Verify Script ist unter <ahref="http://verify.pnp4nagios.org"class="urlextern"title="http://verify.pnp4nagios.org"rel="nofollow">http://verify.pnp4nagios.org</a> verfügbar.
Die wichtigste Infos ist der zu prüfende Modus, welcher mit der Option <code>--mode</code> angegeben wird.<br/>
Weitere Infos über die einzelnen Modi und deren Konfiguration unter <ahref="/de/pnp-0.6/modes"class="wikilink1"title="de:pnp-0.6:modes">"Welcher Modus ist für mich richtig ?"</a> und <ahref="/de/pnp-0.6/config"class="wikilink1"title="de:pnp-0.6:config">"Konfiguration"</a>
Beginnend mit <code>0.6.19-R.37</code> (2013-02-17) akzeptiert das Skript die Option<code>--object</code> (oder <code>-o</code>) gefolgt von einer Zeichenkette, die einen Host und/oder einen Service angibt. Für diese/s Objekt(e) werden die Performance-Daten angegeben (falls vorhanden). Die Daten werden von eckigen Klammern begrenzt, gefolgt vom Wert der Direktive <code>process_performance_data</code> (<code>ppd</code>=n).
</p>
<p>
<code>host</code> = Performance-Informationen für den Host <code>host</code> zeigen<br/>
<code>;service</code> = Performance-Informationen für Service <code>service</code> zeigen<br/>
<code>host;service</code> = Performance-Informationen für Service <code>service</code> auf Host <code>host</code> zeigen
</p>
<p>
Die Zeichenketten werden als reguläre Ausdrücke angesehen (<acronymtitle="Practical Extraction and Report Language">Perl</acronym>-Syntax).
<h1><aname="das_nagios_web_frontend"id="das_nagios_web_frontend"href="/de/pnp-0.6/webfe"title="Das Nagios Web Frontend">Das Nagios Web Frontend</a></h1>
<divclass="level1">
<p>
PNP soll natürlich schnell erreichbar sein. Man möchte nicht lange nach den richtigen Graphen suchen.
</p>
<p>
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.
Bis Nagios 2.x erfolgt die Einbindung externer URLs in das Nagios-Web-Interface über die <ahref="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#serviceextinfo"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#serviceextinfo"rel="nofollow">Extended-Info-Objekte</a>. Für PNP verwenden wir die Option action_url, um das PNP-Web-Frontend mit den passenden Optionen aufzurufen.
Dieses Template kann nun über “use srv-pnp” in der serviceextinfo-Definition verwendet werden. Wenn Sie die Schnellstart-Installationsanleitungen benutzt haben, können Sie beispielsweise in der Datei localhost.cfg die Definitionen wie folgt erweitern:
Seit Nagios 3.0 ist die Direktive action_url in die <ahref="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#host"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#host"rel="nofollow">Host</a>- bzw. <ahref="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#service"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#service"rel="nofollow">Service</a>-Definition verschoben worden. Die <ahref="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#serviceextinfo"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#serviceextinfo"rel="nofollow">serviceextinfo</a>- und <ahref="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#hostextinfo"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/objectdefinitions#hostextinfo"rel="nofollow">hostextinfo</a>-Definitionen sind entfallen. Damit wird die Definition der URLs zum PNP-Interface wesentlich vereinfacht.
</p>
<p>
Zuerst definieren wir zwei Nagios-Templates. Falls Sie die <ahref="http://www.nagios-wiki.de/nagios/doku3/quickstart"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/quickstart"rel="nofollow">Schnellstart-Installationsanleitungen</a> für Nagios benutzt haben, können Sie die folgenden Zeilen der Datei templates.cfg hinzufügen:
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:
</p>
<preclass="code">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
}
</pre>
<preclass="code">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%
}
</pre>
<p>
Die Links auf die richtigen URLs werden automagisch erstellt.
Außerdem gibt es die Möglichkeit, die Graphen bereits in der Statusübersicht beim Überfahren des “Action Url Icons” mit der Maus einzublenden.
</p>
<p>
Ermöglicht wird dies durch die <ahref="http://nagios.sourceforge.net/docs/3_0/cgiincludes.html"class="urlextern"title="http://nagios.sourceforge.net/docs/3_0/cgiincludes.html"rel="nofollow">CGI Includes</a>, die es uns erlauben, Javascript-Code an geeigneter Stelle im Seitenkopf der Statusübersicht einzubinden ( status.cgi ).
</p>
<p>
In den PNP-Quellen ist die Datei <code>contrib/ssi/status-header.ssi</code> bereits enthalten, die verwendeten URLs müssen aber unter Umständen angepasst werden. Wir gehen hier davon aus, dass PNP über <code>/pnpnagios/index.php</code> erreichbar ist.
</p>
<p>
Die besagte Datei muss in das Verzeichnis <code>/usr/local/nagios/share/ssi/</code> kopiert werden und darf <strong>NICHT</strong> ausführbar sein. Nagios würde die Datei sonst wirklich wie ein <acronymtitle="Common Gateway Interface">CGI</acronym> behandeln und ausführen, was aber in diesem Fall zu Fehlern führen würde. Die Apache-Admins mögen bitte “Nagios <acronymtitle="Server Side Includes">SSI</acronym>” nicht mit “Apache <acronymtitle="Server Side Includes">SSI</acronym>” in Verbindung bringen. Beides hat nichts miteinander zu tun.
<h1><aname="pnp_web_frontend"id="pnp_web_frontend"href="/de/pnp-0.6/webfe_cfg"title="PNP Web Frontend">PNP Web Frontend</a></h1>
<divclass="level1">
<p>
Das Verhalten des PNP-Web-Frontend lässt sich über die Config-Datei <code>etc/config.php</code> beeinflussen.
Diese Datei wird bei Updates von PNP immer wieder überschrieben, da die meisten Pfade und Optionen bereits durch <code>./configure</code> ermittelt werden.
</p>
<p>
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.
Bildschirmdimensionen ändern sich, Blattgrößen nicht. Um unterschiedliche Einstellungen zu ermöglichen, können für die Generierung von <acronymtitle="Portable Document Format">PDF</acronym>-Dateien eigene Werte definiert werden. Wenn diese Variablen nicht definiert sind, werden die Werte der Graphen benutzt.
Zusätzliche Optionen, die bei jedem Aufruf von RRDTool mit übergeben werden. Beispielsweise <code>--slope-mode</code>, um die Graphen etwas zu glätten.
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.
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.
Sie können hier auch weitere Views definieren, sollten aber dabei berücksichtigen, dass im Normalfall ALLE definierten Views angezeigt werden.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/timeranges"class="wikilink1"title="de:pnp-0.6:timeranges">Timeranges</a>
In der Übersicht zeigt PNP fünf Zeitbereiche, die frei in der config.php definiert werden können.
</p>
<p>
Es gibt aber auch die Möglichkeit, die Zeitbereiche über die <acronymtitle="Uniform Resource Locator">URL</acronym> zu beeinflussen. Dies ist hilfreich, wenn z.B. automatisch <acronymtitle="Portable Document Format">PDF</acronym>-Dokumente erstellt werden sollen
</p>
<p>
Die Zeitbereiche werden über die Optionen <code>start</code> und <code>end</code> definiert.
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 <code>end</code> lässt sich über diesen Weg beeinflussen, wobei beide Optionen auch einzeln manipuliert werden dürfen.
</p>
<tableclass="inline">
<trclass="row0">
<thclass="col0"> start </th><thclass="col1"> end </th><thclass="col2"> view </th><thclass="col3"> Ergebnis </th>
</tr>
<trclass="row1">
<tdclass="col0 leftalign"></td><tdclass="col1 leftalign"></td><tdclass="col2 leftalign"></td><tdclass="col3">Alle Ansichten enden mit der aktuellen Zeit </td>
</tr>
<trclass="row2">
<tdclass="col0 centeralign"> x </td><tdclass="col1 leftalign"></td><tdclass="col2 leftalign"></td><tdclass="col3">Alle Ansichten beginnen mit dem angegebenen Datum </td>
</tr>
<trclass="row3">
<tdclass="col0 leftalign"></td><tdclass="col1 centeralign"> x </td><tdclass="col2 leftalign"></td><tdclass="col3">Alle Ansichten enden mit dem angegebenen Datum </td>
</tr>
<trclass="row4">
<tdclass="col0 centeralign"> x </td><tdclass="col1 centeralign"> x </td><tdclass="col2 leftalign"></td><tdclass="col3">Eine Ansicht zwischen den beiden Zeitangaben </td>
</tr>
<trclass="row5">
<tdclass="col0 leftalign"></td><tdclass="col1 leftalign"></td><tdclass="col2 centeralign"> x </td><tdclass="col3">Eine Ansicht endet mit der aktuellen Zeit </td>
</tr>
<trclass="row6">
<tdclass="col0 centeralign"> x </td><tdclass="col1 leftalign"></td><tdclass="col2 centeralign"> x </td><tdclass="col3">Eine Ansicht beginnt mit dem angegebenen Datum </td>
</tr>
<trclass="row7">
<tdclass="col0 leftalign"></td><tdclass="col1 centeralign"> x </td><tdclass="col2 centeralign"> x </td><tdclass="col3">Eine Ansicht endet mit dem angegebenen Datum </td>
</tr>
</table>
<p>
Beispiele zur Datumsangabe:
</p>
<tableclass="inline">
<trclass="row0">
<thclass="col0 centeralign"> Format </th><thclass="col1 leftalign"> Beschreibung </th>
<tdclass="col0"> 2011102322:50:00 </td><tdclass="col1"> 23.10.2011 ab 22:50:00 Uhr</td>
</tr>
</table>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/pages"class="wikilink1"title="de:pnp-0.6:pages">Pages</a>
„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 <code>config.php</code> durch den Konfigurationseintrag „$conf['page_dir']“ angegeben wurde, enthält ein oder mehrere Dateien mit der Endung „.cfg“.
</p>
<p>
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.<br/>
Die Bezeichnung hinter <code>page_name</code> erscheint in der Liste der verfügbaren Seiten und wird als Titel im Browser angezeigt.
<strong>Achtung:</strong> “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.
Danach folgen ein oder mehrere „graph“-Definitionen:
</p>
<preclass="code">define graph {
host_name host1,host2,host3
service_desc Current_Load
}</pre>
<p>
<strong>Achtung:</strong> Damit die oben gezeigte Liste von Host-Namen funktioniert, muss <code>use_regex 0</code> gesetzt sein!
</p>
<preclass="code">define graph {
host_name host4
service_desc Current_Users
}</pre>
<p>
Und jetzt mit regulären Ausdrücken. Zuerst alle Hosts, deren Name mit „Tape“ beginnen:
</p>
<preclass="code">define graph {
host_name ^Tape
service_desc Traffic
}</pre>
<p>
alle Hosts, deren Namen mit “00” enden
</p>
<preclass="code">define graph {
host_name 00$
service_desc Load
}</pre>
<p>
alle Services des localhost, deren Namen ein „a“ oder „o“ enthalten:
</p>
<preclass="code">define graph {
host_name localhost
service_desc a|o
}</pre>
<p>
alle Services, die im Namen nach einem „_“ (mindestens) drei Ziffern haben auf allen Hosts, deren Namen mit „UX“ beginnen:
</p>
<preclass="code">define graph {
host_name ^UX
service_desc _\d{3}
}</pre>
<p>
In einigen Fällen möchten Sie vielleicht die Anzeige auf einen Graphen beschränken. Um dies zu erreichen, können Sie die optionale Direktive “source” benutzen, gefolgt von einer Zahl, die die Position in der RRD-Datei angibt. Die Zählung beginnt ab 0
</p>
<preclass="code">define graph {
host_name host1,host2,host3
service_desc PING
source 1
}</pre>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/xport"class="wikilink1"title="de:pnp-0.6:xport">Datenexport</a>
PNP bietet über den <code>xport</code> Controller Zugriff auf die RRD-Daten. Dabei kann das Ausgabeformat gewählt werden. Zur Zeit sind die Formate <code>xml</code>, <code>json</code> und <code>csv</code> realisiert.
</p>
<p>
Aufgerufen wird der Controller über die <acronymtitle="Uniform Resource Locator">URL</acronym>
<code>view=<n></code> begrenzt den Graphen auf die Zeitperiode, die in <code>config.php</code> definiert ist<br/>
<code>source=<n></code> zeigt nur eine Data-Source, wenn mehrere in der RRD-Datei vorhanden sind
</p>
<p>
Anstatt <code>view</code> können Sie auch <code>start</code> und/oder <code>end</code> benutzen, um die Zeitspanne anzugeben. Details finden Sie in den <ahref="/de/pnp-0.6/timeranges"class="wikilink1"title="de:pnp-0.6:timeranges">"time ranges"</a>.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/tpl"class="wikilink1"title="de:pnp-0.6:tpl">Templates</a>
<h1><aname="was_sind_templates"id="was_sind_templates"href="/de/pnp-0.6/tpl"title="Was sind Templates ?">Was sind Templates ?</a></h1>
<divclass="level1">
<p>
PNP benutzt Templates, um das Aussehen der RRD-Graphen zu beeinflussen.
</p>
<p>
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.
</p>
</div>
<h2><aname="wann_wird_welches_template_verwendet"id="wann_wird_welches_template_verwendet">Wann wird welches Template verwendet ?</a></h2>
<divclass="level2">
<p>
Templates werden an zwei Stellen im Dateisystem gespeichert.
</p>
<ul>
<liclass="level1"><divclass="li"> share/templates.dist - für Templates, die im PNP-Paket bereits enthalten sind.</div>
</li>
<liclass="level1"><divclass="li"> share/templates - für selbst erstellte Templates. Diese werden bei Updates nicht verändert.</div>
</li>
</ul>
<p>
Weiterhin können seit Version 0.6.5 weitere Template Verzeichnisse in der Config Datei <code>pnp4nagios/etc/config.php</code> hinzugefügt werden.
</p>
<p>
Soll der Graph für den Service “http” auf Host “localhost” angezeigt werden, so sucht PNP zuerst nach der <acronymtitle="Extensible Markup Language">XML</acronym>-Datei <code>perfdata/localhost/http.xml</code> und liest diese ein. Diese <acronymtitle="Extensible Markup Language">XML</acronym>-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 <acronymtitle="Extensible Markup Language">XML</acronym>-Tags <code><TEMPLATE></code>, welches PNP-Template für diesen Graphen verwendet werden soll.
PNP-Templates sind <acronymtitle="Hypertext Preprocessor">PHP</acronym>-Dateien, die zur Laufzeit von PNP über die <acronymtitle="Hypertext Preprocessor">PHP</acronym>-Funktion include() eingebunden werden.
Dies bedeutet, dass jeder <acronymtitle="Hypertext Preprocessor">PHP</acronym>-Code in Templates interpretiert wird. Daher ist die Manipulation aller Werte über <acronymtitle="Hypertext Preprocessor">PHP</acronym> möglich.
<liclass="level1"><divclass="li"> Templates dürfen keine Ausgabe erzeugen.</div>
</li>
<liclass="level1"><divclass="li"> innerhalb der Templates werden die zwei Arrays $opt[] und $def[] gefüllt.</div>
</li>
</ol>
<p>
Die beiden <acronymtitle="Hypertext Preprocessor">PHP</acronym>-Arrays $opt[] und $def[] zusammen bilden den Aufruf von <code>'rrdtool graph</code>'. Somit sind alle Optionen möglich, die RRDtool bietet. Die Optionen von RRDtool sind auf der <ahref="http://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html"class="urlextern"title="http://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html"rel="nofollow">RRDtool Homepage</a> genauestens beschrieben.
</p>
<p>
Wenn beide Arrays mehrere Datensätze enthalten, so wird für jeden Datensatz ein Graph erstellt.
</p>
<p>
Weiterhin stehen innerhalb der Templates die Daten aus dem zugehörigen <acronymtitle="Extensible Markup Language">XML</acronym>-File zur Verfügung, die zum Erstellen der Graphen wieder verwendet werden können.
</p>
<p>
Am Beispiel des recht einfachen Templates response.php lassen sich die wichtigsten Optionen recht gut beschreiben.
</span><spanclass="re0">$opt</span><spanclass="br0">[</span><spanclass="nu0">1</span><spanclass="br0">]</span><spanclass="sy0">=</span><spanclass="st0">"--title <spanclass="es1">\"</span>Response Time For <spanclass="es4">$hostname</span> / <spanclass="es4">$servicedesc</span><spanclass="es1">\"</span>"</span><spanclass="sy0">;</span>
<spanclass="re0">$def</span><spanclass="br0">[</span><spanclass="nu0">1</span><spanclass="br0">]</span><spanclass="sy0">.=</span><spanclass="st0">"AREA:var1#00FF00:<spanclass="es1">\"</span>Response Times <spanclass="es1">\"</span>"</span><spanclass="sy0">;</span>
<spanclass="re0">$def</span><spanclass="br0">[</span><spanclass="nu0">1</span><spanclass="br0">]</span><spanclass="sy0">.=</span><spanclass="st0">"GPRINT:var1:LAST:<spanclass="es1">\"</span>%3.4lg <spanclass="es6">%s</span><spanclass="es4">$UNIT[1]</span> LAST <spanclass="es1">\"</span>"</span><spanclass="sy0">;</span>
<spanclass="re0">$def</span><spanclass="br0">[</span><spanclass="nu0">1</span><spanclass="br0">]</span><spanclass="sy0">.=</span><spanclass="st0">"GPRINT:var1:MAX:<spanclass="es1">\"</span>%3.4lg <spanclass="es6">%s</span><spanclass="es4">$UNIT[1]</span> MAX <spanclass="es1">\"</span>"</span><spanclass="sy0">;</span>
<spanclass="re0">$def</span><spanclass="br0">[</span><spanclass="nu0">1</span><spanclass="br0">]</span><spanclass="sy0">.=</span><spanclass="st0">"GPRINT:var1:AVERAGE:<spanclass="es1">\"</span>%3.4lg <spanclass="es6">%s</span><spanclass="es4">$UNIT[1]</span> AVERAGE <spanclass="es1">\"</span>"</span><spanclass="sy0">;</span>
<spanclass="sy1">?></span></pre>
<p>
<strong><code>$opt[1] = ”--title …”</code></strong> 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 <code>$hostname</code> und <code>$servicedesc</code> sind durch den Aufruf von PNP ermittelt worden und stehen nun auch im Template zur Verfügung.
</p>
<p>
<strong><code>$def[1] = “DEF:var1=$RRDFILE[1]:$DS[1]:AVERAGE ”;</code></strong> definiert, welche Daten aus welchem RRD-File gelesen werden sollen. $RRDFILE[1] enthält den Pfad zur RRD-Datei dieses Services. $DS[1] verweist auf die Datenreihe eins aus der RRD-Datei.
</p>
<p>
<strong><code>$def[1] .= “AREA:var1#00FF00:\”Response Times \” ”;</code></strong> durch den Operator ”.=” werden weitere Daten an das Array $def[1] angehängt. 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.
</p>
<p>
<strong><code>$def[1] .= “LINE1:var1#000000 ”;</code></strong> Als Abschluss der eben gezeichneten Fläche wird eine Linie (LINE1) in Schwarz (#000000) gezeichnet.
</p>
<p>
<strong><code>$def[1] .= “GPRINT:var1:LAST:\”%3.4lg %s$UNIT[1] LAST \” ”; <br/>
$def[1] .= “GPRINT:var1:MAX:\”%3.4lg %s$UNIT[1] MAX \” ”; <br/>
$def[1] .= “GPRINT:var1:AVERAGE:\”%3.4lg %s$UNIT[1] AVERAGE \” ”;</code></strong>
</p>
<p>
Die drei GPRINT Zeilen bilden die Legende des Graphen. Die aktuellen Werte werden dabei über die <ahref="http://en.wikipedia.org/wiki/printf"class="interwiki iw_wp"title="http://en.wikipedia.org/wiki/printf">printf</a> Syntax formatiert.
PNP speichert über den Datensammler <code>process_perfdata.pl</code> zur Laufzeit nicht nur Performancedaten, sondern auch weitere von Nagios exportierte Werte. Diese Werte werden in der jeweils für den Service gültigen <acronymtitle="Extensible Markup Language">XML</acronym>-Datei gespeichert.
</p>
<p>
Im ersten Teil der <acronymtitle="Extensible Markup Language">XML</acronym>-Datei werden die Performancedaten in ihre Einzelteile zerlegt gespeichert.
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.
</p>
<p>
Im Array <code>$UNIT[1]</code> ist somit die Einheit der ersten Datenreihe gespeichert.
</p>
<p>
Die <acronymtitle="Extensible Markup Language">XML</acronym>-Datei enthält jedoch noch weitere Informationen. Wird <code>process_perdata.pl</code> im sync-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.
<spanclass="sc3"><spanclass="re1"><NAGIOS_SERVICEOUTPUT<spanclass="re2">></span></span></span>HTTP OK HTTP/1.1 200 OK - 10087 bytes in 0.125 seconds<spanclass="sc3"><spanclass="re1"></NAGIOS_SERVICEOUTPUT<spanclass="re2">></span></span></span>
Die einzelnen <acronymtitle="Extensible Markup Language">XML</acronym>-Felder sind als Variablen in den PNP-Templates verwendbar, wobei jedes Feld als Variable gleichen Namens verfügbar ist.
</p>
<p>
Aus <code><NAGIOS_SERVICEOUTPUT></code> wird die Variable <code>$NAGIOS_SERVICEOUTPUT</code>.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/tpl_custom"class="wikilink1"title="de:pnp-0.6:tpl_custom">Custom Templates</a>
Wie bereits unter ”<ahref="/de/pnp-0.6/tpl"class="wikilink1"title="de:pnp-0.6:tpl">Was sind Templates ?</a>” beschrieben, ist die Darstellung der Graphen abhängig vom verwendeten Check-Command.
</p>
<p>
Es gibt jedoch Situationen, in denen dieses Verhalten übersteuert werden muss, zum Beispiel dann wenn allgemeingültige Commands definiert wurden.
</p>
<p>
PNP, speziell process_perfdata.pl, sucht zur Laufzeit für jedes check_command im Verzeichnis etc/check_commands nach einer Config-Datei (<check_command>.cfg) und liest diese, wenn vorhanden, ein.
Geht man von folgendem Beispiel einer Nagios command-Definition aus:
</p>
<preclass="code">
define command {
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a "$ARG2$"
}
</pre>
<p>
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.
</p>
<p>
Da unser Beispiel-Command check_nrpe lautet, wird nach etc/check_commands/check_nrpe.cfg gesucht.
</p>
<p>
Eine Beispiel-Config wird bereits während der Installation mit der Dateierweiterung .cfg-sample in etc/check_commands gespeichert.
</p>
<preclass="code">
# check_command check_nrpe!load!-w 4,4,4 -c 5,5,5
# ________0__________| | |
# ________1__________________| |
# ________2__________________________|
#
CUSTOM_TEMPLATE = 1
</pre>
<p>
<code>CUSTOM_TEMPLATE = 1</code> 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”
Weitere Datentypen sind in der RRDTool-Dokumentation unter <ahref="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"class="urlextern"title="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"rel="nofollow">rrdcreate</a> erklärt.
</p>
<p>
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
</p>
</div>
<h2><aname="use_min_on_create_und_use_max_on_create"id="use_min_on_create_und_use_max_on_create">USE_MIN_ON_CREATE und USE_MAX_ON_CREATE</a></h2>
<divclass="level2">
<p>
In einigen wenigen Situationen ist es notwendig, die für RRDTool gültigen Daten zu begrenzen.
</p>
<p>
RRD-Datenbanken lassen sich mit definierten Minimum- und Maximum-Werten anlegen.
Weitere Infos unter <ahref="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"class="urlextern"title="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"rel="nofollow">http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html</a>
</p>
<p>
Berücksichtigen des Maximum-Wertes aus den Performance-Daten
</p>
<preclass="code">USE_MAX_ON_CREATE = 1</pre>
<p>
Berücksichtigen des Minimum-Wertes aus den Performance-Daten
</p>
<preclass="code">USE_MIN_ON_CREATE = 1</pre>
<p>
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
Nach <RRD_HEARTBEAT> Sekunden erwartet RRDtool neue Daten.
</p>
<p>
Mehr dazu unter <ahref="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"class="urlextern"title="http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html"rel="nofollow">http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html</a>
</p>
<p>
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
</p>
</div>
<h2><aname="hints_on_template_names"id="hints_on_template_names">Hints on Template Names</a></h2>
<divclass="level2">
<p>
In den meisten Situationen, kann man erwünsche Template Namen relativ einfach, durch die Verwendung geeignter command Objekt Definitionen, erhalten.
Selbst wenn man “CUSTOM_TEMPLATE = 1” benutz, würde man template Namen wie diesen “_usr_lib_nagios_plugins_check_load_-w_4,4,4_-c_5,5,5” erhalten, was höchst unerwünscht ist, insbesondere wegen den darin enthaltenen Parametern.
</p>
<p>
<strong>Lösung 1: Die Parameter in eigenständige $ARGn$ auslagern</strong>
</p>
<p>
Eine einfache Lösung ist die Verwendung der folgenden command Objekt Definition:
Natürlich darf “CUSTOM_TEMPLATE = 1” bei dieser Lösung nicht mehr gesetzt werden.
</p>
<p>
Welche der obigen Lösungen verwendet wird, ist weitgehend Geschmacksache.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/advanced"class="wikilink1"title="de:pnp-0.6:advanced">PNP in verteilten Umgebungen</a>
Ist Nagios als verteiltes System implementiert, stellt sich die Frage, wo PNP installiert wird.
</p>
<p>
Rein technisch ist diese Frage nicht wichtig. PNP kann auf den Slaves sowie auf dem Master-Server installiert sein. Oder nur auf dem Master?
</p>
<p>
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.
</p>
<p>
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.
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.
</p>
<p>
Die Nagios-Dokumentation zu diesem Thema ist <ahref="http://www.nagios-wiki.de/nagios/doku3/distributed"class="urlextern"title="http://www.nagios-wiki.de/nagios/doku3/distributed"rel="nofollow">hier</a> zu finden. Das in der Doku verwendete Command ist leicht anzupassen.
Das Plugin <ahref="http://my-plugin.de/wiki/projects/check_multi/start"class="urlextern"title="http://my-plugin.de/wiki/projects/check_multi/start"rel="nofollow">check_multi</a> 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.
</p>
<p>
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.
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">Zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/rrdcached"class="wikilink1"title="de:pnp-0.6:rrdcached">rrdcached-Unterstützung</a>
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.
</p>
<p>
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.
</p>
<p>
In der aktuellen RRDtool-Version ( <ahref="http://oss.oetiker.ch/rrdtool-trac/browser/trunk/program"class="urlextern"title="http://oss.oetiker.ch/rrdtool-trac/browser/trunk/program"rel="nofollow">SVN trunk 1550+</a> ) ist der rrdcached enthalten, der genau diese Situation verbessern soll.
</p>
<p>
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 <ahref="http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/index.html"class="urlextern"title="http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/index.html"rel="nofollow">rrd-developers</a> Mailingliste koordiniert.
Der rrdcached arbeitet als Daemon im Hintergrund und öffnet einen UNIX- oder TCP-Socket, auf dem er auf Anfragen von rrdtool wartet. Aufgrund von Sicherheitsbedenken ist es in neueren Versionen von rrdcached aber nicht mehr möglich absolute Pfadangaben (wie bei pnp4nagios üblich) bei Netzwerkzugriffen zu verwenden, daher ist derzeit nur Nutzung von UNIX-Sockets möglich.
Der rrdcached kennt einige wichtige Optionen, die beim Start übergeben werden.
</p>
<p>
Option -l definiert den Socket, auf dem der rrdcached Requests annimmt. Der Default-UDP-Port ist 42217, der Default-UNIX-Socket /tmp/rrdcached.sock.
</p>
<preclass="code">
-l unix:/pfad/zum/rrdcached.sock
-l /pfad/zum/rrdcached.sock
-l 127.0.0.1
-l 127.0.0.1:8888
</pre>
<p>
Option -P gibt die für die nachfolgenden Sockets (mit -l spezifiziert) erlaubten Befehle an, welche auf die RRD-Datenbanken angewendet werden können.
</p>
<preclass="code">-P FLUSH,PENDING</pre>
<p>
Option -s erlaubt es die Gruppenzugehörigkeit der nachfolgenden UNIX-Sockets zu ändern.
</p>
<preclass="code">-s nagios</pre>
<p>
Option -m setzt die Zugriffsrechte für die nachfolgenden UNIX-Sockets auf die (in oktal) angegebenen Werte.
</p>
<preclass="code">-m 0660</pre>
<p>
Option -w bestimmt den Intervall in Sekunden, in dem die Daten auf Disk geschrieben werden sollen.
</p>
<preclass="code">-w 1800</pre>
<p>
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.
</p>
<preclass="code">-z 1800</pre>
<p>
Option -p definiert ein PID File
</p>
<preclass="code">-p /var/run/rrdcached.pid</pre>
<p>
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.
</p>
<preclass="code">-j /var/cache/rrdcached</pre>
<p>
Daraus ergibt sich beispielsweise ein Aufruf von rrdached mit folgenden Parametern
Dies muss natürlich mit den Startoptionen des rrdcached übereinstimmen!
</p>
</div>
<h2><aname="integration_in_pnp"id="integration_in_pnp">Integration in PNP</a></h2>
<divclass="level2">
<p>
Da zwei Bestandteile von PNP auf den rrdcached vorbereitet werden müssen, ergeben sich Änderungen in zwei Config-Files. Außerdem muß der User unter welchem der Webserver läuft zur Gruppe unter der Nagios läuft hinzugefügt werden.
</p>
<p>
1. Anpassen der <code>process_perfdata.cfg</code> für den Datensammler <code>process_perfdata.pl</code>
</p>
<preclass="code">
# EXPERIMENTAL rrdcached Support
# Use only with rrdtool svn revision 1511+
#
RRD_DAEMON_OPTS = unix:/var/run/rrdcached.sock
</pre>
<p>
2. Anpassen der <code>config_local.php</code> (bzw. config.php) für das Webinterface
Die passenden Optionen sind bereits in den Beispieldateien enthalten.
</p>
<p>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/rrd_convert"class="wikilink1"title="de:pnp-0.6:rrd_convert">migrieren von RRD-Dateien</a>
In großen Nagios-Installationen kann es zu nicht akzeptierbaren Verspätungen seitens der Checks kommen. Das bedeutet, dass Nagios einen Check zum Zeitpunkt <code>x</code> ausführen soll, diesen aber erst <code>y</code> Sekunden später tatsächlich ausführt.
</p>
<p>
Wenn man dem Nagios-Daemon mitteilt, dass man nach jedem einzelnen Check auch die Performance-Daten 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.
</p>
<p>
Um die Anzahl der Aktionen pro Check zu verringern, kann man nun PNP im <ahref="/de/pnp-0.6/modes#bulk_mode"class="wikilink1"title="de:pnp-0.6:modes">Bulk-Mode</a> verwenden, wobei die Performance-Daten zunächst vom Nagios-Prozess gesammelt und anschließend ebenfalls vom Nagios-Prozess selbst verarbeitet werden.
</p>
<p>
Man kann aber auch dem Nagios-Prozess mitteilen, dass die Verarbeitung der Performance-Daten lediglich durch das Verschieben der Dateien in ein Spool-Verzeichnis 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 Performance-Daten-Verarbeitung durch das schnelle Verschieben der Datei bereits erledigt, aber das bringt die Performance-Daten noch nicht in die RRD-Datenbank.
</p>
<p>
Um den Transport der Performance-Daten-Dateien kümmert sich nun der NPCD-Daemon, unabhängig vom Nagios-Prozess, indem er regelmäßig in das Spool-Verzeichnis guckt und für jede dort gefundene Datei eine Aktion ausführt.
</p>
<p>
Nachdem NPCD gestartet wurde, erstellt er sich eine Liste von Dateinamen des Spool-Verzeichnisses und startet für jede gefundene Datei einen Thread zur weiteren Verarbeitung mit Hilfe des <code>perfdata_file_run_cmd</code> und dem optionalen <code>perfdata_file_run_cmd_arg</code> als zusätzlichem Argument.
</p>
<p>
Da das Format der Performance-Daten-Dateien dem Format der 'normalen' PNP-Bulk-Modus-Dateien gleicht, kann NPCD nun für jede gefundene Datei also <code>process_perfdata.pl</code> im <ahref="/de/pnp-0.6/modes#bulk_mode"class="wikilink1"title="de:pnp-0.6:modes">Bulk Modus</a> aufrufen.
</p>
</div>
<h2><aname="vor-_und_nachteile"id="vor-_und_nachteile">Vor- und Nachteile</a></h2>
<liclass="level2"><divclass="li"> aufgrund der vom Nagios-Prozess getrennten Verarbeitung der Performance-Daten hat Nagios mehr Zeit für die wichtigen Dinge</div>
</li>
</ul>
</li>
<liclass="level1"><divclass="li"> kein Datenverlust</div>
<ul>
<liclass="level2"><divclass="li"> solange Nagios Performance-Daten-Dateien im Spool-Verzeichnis ablegt, gehen keine Daten verloren. Selbst wenn der NPCD mal nicht laufen sollte (Bsp. nach Neustart des Systems), werden die Dateien nach Wiederanlauf in chronologischer Reihenfolge bearbeitet ($TIMET$ Makro beim verschieben ins Spool-Verzeichnis)</div>
</li>
</ul>
</li>
</ul>
<p>
<strong>Kontra:</strong>
</p>
<ul>
<liclass="level1"><divclass="li"> Keine Echtzeitverarbeitung der Performance-Daten</div>
<ul>
<liclass="level2"><divclass="li"> aufgrund des Rhythmusses, wann Nagios die Performance-Daten-Dateien verschiebt (<code>service_perfdata_file_processing_interval</code>)</div>
</li>
<liclass="level2"><divclass="li"> nach jedem Lauf durch alle Dateien des Spool-Verzeichnisses wartet NPCD 10 Sekunden lang auf neue Dateien</div>
NPCD muss zwangsläufig über eine Konfigurationsdatei gesteuert werden. Eine Beispielkonfiguration liegt der PNP-Installation als <code>npcd.cfg-sample</code> bei.
</p>
<p>
Nach Umbenennen der <code>-sample</code> Datei zu <code>npcd.cfg</code> kann NPCD nun wie folgt gestartet werden:
um NPCD im Hintergrund als Daemon laufen zu lassen.
</p>
<p>
<strong>Hinweis:</strong>
Die <code>-sample</code> Datei sollte in jedem Fall in <code>npcd.cfg</code> umbenannt werden, da sie sonst bei einem Update von PNP überschrieben werden könnte.
<liclass="level3"><divclass="li"> NPCD wird nach Erreichen der hier angegebenen Dateigröße eigenständig eine Logrotation durchführen</div>
<liclass="level3"><divclass="li"><imgsrc="/lib/images/smileys/icon_exclaim.gif"class="middle"alt=":!:"/> Die Kommandozeile wird nach folgendem Schema aufgebaut: <preclass="code"><perfdata_file_run_cmd><perfdata_file_run_cmd_args><filename_from_perfdata_spool_dir></pre>
<liclass="level3"><divclass="li"> wenn <code>use_load_threshold</code> auf 1 gesetzt ist, werden bei Erreichen dieses load limits keine neuen Threads gestartet</div>
<ahref="/de/pnp-0.6/start"class="wikilink1"title="de:pnp-0.6:start">zurück zur Übersicht</a> | <ahref="/de/pnp-0.6/wrapper"class="wikilink1"title="de:pnp-0.6:wrapper">Wrapper-Script</a>
<liclass="level1"><divclass="li"> die Bezeichnung muss in Apostrophe eingeschlossen sein, wenn diese Gleichheitszeichen (<code>=</code>), Apostroph (<code></code>') oder Leerzeichen (<code></code>) enthält, ansonsten sind die Apostrophe optional</div>
</li>
<liclass="level1"><divclass="li"> die Länge der Bezeichnung ist beliebig, aber idealerweise sind die ersten 19 Zeichen eindeutig (aufgrund einer Beschränkung in RRD). Bitte beachten Sie, dass es eine Längenbegrenzung bei der Menge von Daten gibt, die von NRPE an Nagios geliefert werden kann</div>
</li>
<liclass="level1"><divclass="li"> um ein Apostroph darzustellen, nutzen Sie zwei einzelne Apostrophe</div>
</li>
<liclass="level1"><divclass="li"><em>warn</em>, <em>crit</em>, <em>min</em> und/oder <em>max</em> können leer sein (z.B. wenn der Schwellwert nicht definiert ist oder wenn min oder max nicht zutreffen). Nachfolgende, nicht gefüllte Semikola können entfallen</div>
</li>
<liclass="level1"><divclass="li"><em>min</em> und <em>max</em> sind nicht erforderlich, wenn UOM = %</div>
</li>
<liclass="level1"><divclass="li"><em>Wert</em>, <em>min</em> und <em>max</em> sind aus der Klasse [-0-9.] (Ziffern, Minuszeichen und Dezimalpunkt). Alle müssen das gleiche UOM benutzen</div>
</li>
<liclass="level1"><divclass="li"><em>warn</em> und <em>crit</em> sind im “Range”-Format (siehe Abschnitt 2.5 der Original-Dokumentation). Alle müssen das gleiche UOM benutzen.</div>
</li>
<liclass="level1"><divclass="li"> UOM (unit of measurement, Maßeinheit) ist eins von:</div>
<ul>
<liclass="level3"><divclass="li"> keine Einheit angegeben - angenommen wird eine Zahl (int oder float) von Dingen (z.B. Benutzer, Prozesse, Load)</div>
</li>
<liclass="level3"><divclass="li"> s - Sekunden (auch us, ms)</div>
