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, zum Beispiel dann wenn allgemeingültige Commands definiert wurden.
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. Folgende Optionen können darin definiert werden:
Geht man von folgendem Beispiel einer Nagios command-Definition aus:
define command {
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a "$ARG2$"
}
Die Folge wäre, dass immer das Template check_nrpe.php verwendet werden würde, auch wenn auf dem zu überwachenden Server via NRPE ein ganz anderes Plugin aufgerufen wurde.
Da unser Beispiel-Command check_nrpe lautet, wird nach etc/check_commands/check_nrpe.cfg gesucht.
Eine Beispiel-Config wird bereits während der Installation mit der Dateierweiterung .cfg-sample in etc/check_commands gespeichert.
# check_command check_nrpe!load!-w 4,4,4 -c 5,5,5 # ________0__________| | | # ________1__________________| | # ________2__________________________| # CUSTOM_TEMPLATE = 1
CUSTOM_TEMPLATE = 1 sorgt dafür, dass nur der Inhalt von $ARG1$ als Template-Name verwendet wird. Da in diesem Beispiel $ARG1$ mit dem Wert “load” gefüllt ist, ergibt sich als Template-Name “load.php”
CUSTOM_TEMPLATE = 0,1 ergibt → “check_nrpe_load.php”
CUSTOM_TEMPLATE = 1,0 ergibt → “load_check_nrpe.php”
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
Über die Option “DATATYPE” kann beeinflusst werden, mit welchem Datentyp die RRD-Datenbank angelegt werden soll. Default ist in diesem Fall “GAUGE”. Für fortlaufende Werte wird aber hier der Datentyp COUNTER benötigt. Normalerweise sollten Plugin-Entwickler für Daten von Typ Counter die Einheit “c” verwenden. Dies ist jedoch nicht immer der Fall.
Alle Datenreihen auf Typ COUNTER einstellen.
DATATYPE = COUNTER
Einzelnen Datenreihen spezielle Datentypen zuweisen
DATATYPE = GAUGE,GAUGE,COUNTER,COUNTER
Weitere Datentypen sind in der RRDTool-Dokumentation unter rrdcreate erklärt.
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
In einigen wenigen Situationen ist es notwendig, die für RRDTool gültigen Daten zu begrenzen.
RRD-Datenbanken lassen sich mit definierten Minimum- und Maximum-Werten anlegen. Weitere Infos unter http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
Berücksichtigen des Maximum-Wertes aus den Performance-Daten
USE_MAX_ON_CREATE = 1
Berücksichtigen des Minimum-Wertes aus den Performance-Daten
USE_MIN_ON_CREATE = 1
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
RRD_STORAGE_TYPE = SINGLE
Die Option RRD_STORAGE_TYPE definiert die Art der Datenhaltung.
Mögliche Werte sind MULTIPLE und SINGLE
SINGLE: Eine RRD-Datenbank pro Service
MULTIPLE: Ein oder mehrere RRD-Datenbanken pro Service. Für jede Datenreihe wird eine eigene RRD-Datenbank erstellt.
ACHTUNG: Daten werden nicht automatisch migriert!
Ein Konvertierungs-Script finden Sie hier.
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
Gültig ab PNP 0.6.1
RRD_HEARTBEAT = 305
Nach <RRD_HEARTBEAT> Sekunden erwartet RRDtool neue Daten.
Mehr dazu unter http://oss.oetiker.ch/rrdtool/doc/rrdcreate.en.html
Diese Option hat nur Einfluss, wenn die RRD Datenbank neu erstellt wird.
In den meisten Situationen, kann man erwünsche Template Namen relativ einfach, durch die Verwendung geeignter command Objekt Definitionen, erhalten.
Man betrachte folgendes Beispiel:
define command {
command_name check_by_ssh
command_line /usr/bin/ssh $HOSTADDRESS$ $ARG1$
}
mit commands wie diesem:
… check_command check_by_ssh!/usr/lib/nagios/plugins/check_load -w 4,4,4 -c 5,5,5 …
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.
Lösung 1: Die Parameter in eigenständige $ARGn$ auslagern
Eine einfache Lösung ist die Verwendung der folgenden command Objekt Definition:
define command {
command_name check_by_ssh
command_line /usr/bin/ssh $HOSTADDRESS$ $ARG1$ $ARG2$
}
mit commands wie diesem:
… check_command check_by_ssh!/usr/lib/nagios/plugins/check_load!-w 4,4,4 -c 5,5,5 …
(man beachte das hinzugekommene “!”)
Dies funktioniert selbst dann, wann $ARG2$ leer bleibt.
Selbstverständlich müsste man immer noch “CUSTOM_TEMPLATE = 1” setzen.
Lösung 2: Den remote executor in der command Objekt Definition verstecken
Eine andere Lösung ist es, den remote excutor in den jeweiligen command Objekt Definitionen zu verstekcne.
Anstatt folgender Definition:
define command {
command_name check_by_ssh
command_line /usr/bin/ssh $HOSTADDRESS$ $ARG1$ $ARG2$
}
würde man dies für jeden fern auszuführenden command definieren:
define command {
command_name check_load_by_ssh
command_line /usr/bin/ssh $HOSTADDRESS$ /usr/lib/nagios/plugins/check_load $ARG1$
}
mit commands wie diesem:
… check_load_by_ssh!-w 4,4,4 -c 5,5,5 …
Natürlich darf “CUSTOM_TEMPLATE = 1” bei dieser Lösung nicht mehr gesetzt werden.
Welche der obigen Lösungen verwendet wird, ist weitgehend Geschmacksache.