# Custom Templates

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:

## CUSTOM_TEMPLATE

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.

## DATATYPE

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

## USE_MIN_ON_CREATE und USE_MAX_ON_CREATE

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

    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.

## RRD_HEARTBEAT

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.

## Hints on Template Names

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.

zurück zur Übersicht | PNP in verteilten Umgebungen