Irgendwie ging es nicht auf Anhieb: Das lag daran, dass in der Datei /etc/pnp4nagios/apache2.cfg ein paar Nagios-spezifische Dinge drinstanden, die ich der Einfachheit halber rauskommentiert habe:

#       AuthName "Nagios Access"
#       AuthType Basic
#       AuthUserFile /etc/icinga2/htpasswd.users
#       Require valid-user

Wenn man seine PNP4Nagios Installation auf ein neues System mitnehmen will, kann man die rrd-Dateien nicht unbedingt mitnehmen, besonders wenn man die Rechnerarchitektur wechseln muss/will. Damit das doch geht, muss man jede Datei exportieren und auf dem neuen System importieren. Dazu die folgenden beiden scripts, die im Verzeichnis „/var/lib/pnp4nagios/perfdata“ ausgeführt werden müssen

#!/bin/sh
for DATEI in `find . -name *.rrd`
   do
      VERZ=`dirname $DATEI`
      NAME=`basename $DATEI .rrd`
      AUSGABE=$VERZ/$NAME".zml"
      echo "Converting: $DATEI to $AUSGABE"
      rrdtool dump $DATEI >$AUSGABE;
      echo "Copying: $DATEI.zml"
      scp $AUSGABE nane:/var/lib/pnp4nagios/perfdata/$VERZ
      rm $AUSGABE
      echo "--------------------------------------------------"
   done

#!/bin/sh
for DATEI in `find . -name *.zml`
   do
      VERZ=`dirname $DATEI`
      NAME=`basename $DATEI .zml`
      AUSGABE=$VERZ/$NAME".rrd"
      echo "Moving original File $AUSGABE"
      mv $AUSGABE $AUSGABE.bak
      echo "Converting: $DATEI to $AUSGABE"
      rrdtool restore $DATEI $AUSGABE;
#      rm $DATEI
      echo "--------------------------------------------------"
   done

Die Optik der Grafiken wird mit sogenannten Templates gesteuert. Das sind kleine PHP-Schnipsel die offenbar bei der Erzeugung der Grafiken mit eingebunden werden. Sie tragen den Namen des Check-Commands. Schwierig wird es bei den nrpe-checks, denn die würden ja dann alle gleich, nämlich check-nrpe.php heißen

Bisher war es so:

Wenn man Templates für NRPE Checks benutzen will, muss das Konfiguriert werden. Dann stehen in “/etc/pnp4nagios/check_commands“ entsprechende Dateien. Hier beispielhaft einen solche für check_by_nrpe, die eigentlich schon fast selbsterklärend ist. Schließlich wollen wir das Ergebnis des Checks darstellen und nicht nrpe als solches.

# # Adapt the Template if check_command should not be the PNP Template # # check_command check_nrpe!check_disk!20%!10% # 0| | | | # 1_| | | # 2| | # 3| # CUSTOM_TEMPLATE = 1 # # Change the RRD Datatype based on the check_command Name. # Defaults to GAUGE. # # DATATYPE = COUNTER

Hier zeigt sich aber auch schon die Schwierigkeit: Wenn man nämlich, wie wir das gern tun, dem nrpe nur ein Arument übergibt, muss das Template einen ziemlich kryptischen Namen haben, zum Beispiel „check_user_-w_10_-c_20.php“. Das ist doof!

Hinzu kommt, dass man dann nicht ein-und-dasselbe Template für mehrere Checks nehmen kann. Alle möglichen Temperaturen könnte man doch auch mit einem Template abhandeln.

Icinga2 kann das überhaupt nicht! Egal was man in die betreffende .cfg-Datei einträgt! Das liegt daran, dass Icinga2 die einzelnen Teile des Commands nicht mehr mit Ausrufezeichen voneinander trennt. Also PNP4nagios keinen Chance mehr hat, diese auseinanderzufuseln.

In den einschlägigen Internetforen wird diese Problematik mit großer Leidenschaft diskutiert. Ich habe lange gelesen, verschiedenes auch gar nicht verstanden und dann für mich ganz privat eine Lösung gefunden.

Der Name des Templates wird im Programm process-perfdata.pl festgelegt. Da wird viel Mühe darauf verwandt, den Command-Namen herauszufiltern und diesen dann als Template-Namen zu benutzen.

Ich habe ohne nennenswerte Skrupel die Zeile 788 eingefügt:

$template = $NAGIOS{SERVICEDESC};

In dem Hash %NAGIOS steht unter anderem der Name des Service zur Verfügung. Wenn ich die vorher erfolgte Namensbestimmung einfach überschreibe, heißt mein Template nun genauso wie der Service. Eventuelle Leerzeichen werden sogar in Unterstriche umgewandelt. Damit lebe ich ganz prima, ich will aber nicht verhehlen, dass ich in einem der führenden Monitoring-Foren für diese Lösung ziemlich arrogant abgekanzelt wurde, weil ich da offenbar ein religiöses Dogma verletzt habe. Man kann aber auch, wenn man das möchte die Variable $NAGIOS{COMMAND} heranziehen, um sich aus dem Inhalt einen Namen zu destillieren, der sich auf das Command bezieht. Für mich nicht recht brauchbar, aber eher die reine Milch der linientreuen Denkungsart.

Nachdem diese Lösung eine Weile vorzüglich lief, keimte der Wunsch in mir auf, die Templates auf einige wenige zu reduzieren. Schließlich messen wir immer wieder das selbe: Temperaturen, Drehzahlen (oder schlicht Intergers) oder Response Zeiten. Mit diesen drei Templates haben wir schon eine Menge Checks erschlagen.

Die erste Lösung war, diese Grund-Templates mit symbolischen Links mit den Servicenamen zu verbinden. Aber warum sollte man nicht gleich in der Service-Definition den Namen des PNP-Templates festlegen. Icinga 2 erlaubt doch so schöne Variablen???

Ich ging eine Weile mit dem Gedanken schwanger und begann dann, Icinga zu untersuchen: Auf welche Weise transportiere ich eine Variable von der Service-Definition bis in process_perfdata.pl. Zunächst mal definiere ich in einer Servicedefinition die Variable „Vorlage“ (Das Wort „Template“ ist bereits anderweitig vergeben)

Zum Beispiel:

apply Service "Http" {
   import "normal-service"
   check_command = "http"
   vars.vorlage = "Http"
   assign where host.vars.http == "ON"
}

Nach einiger Suche fand ich, wie und wo Icinga die Daten an PNP übergibt und auch die Stelle, wo ich daran etwas verändern konnte: Die Datei /etc/icinga2/features_enabled/perfdata.conf ist so gut wie leer, aber man darf eine Zeile wie die folgende hineinschreiben:

service_format_template = "DATATYPE::SERVICEPERFDATA\tTIMET::$icinga.timet$\tHOSTNAME::$host.name$\tSERVICEDESC::$service.name$\tSERVICEPERFDATA::$service.perfdata$\tSERVICECHECKCOMMAND::$service.check_command$\tHOSTSTATE::$host.state$\tHOSTSTATETYPE::$host.state_type$\tSERVICESTATE::$service.state$\tSERVICESTATETYPE::$service.state_type$\tVORLAGE::$vorlage$"

Dieser ganze Sermon muss in EINE Zeile!!! wichtig ist dabei nur das letzte Statement: VORLAGE::$vorlage$„, denn damit wird dem NAGIOS-Hash das Wertepaar VORLAGE/$vorlage$ hinzugefügt, wobei $vorlage nichts anderes enthält als den Variableninhalt aus unserer Servicedefinition.

Nun ist der Rest einfach:

Die Datei /usr/lib/pnp4nagios/libexec/process_perfdata.pl wird mit ein paar Zeilen angepasst:

    else {
        print_log( "No Custom Template found for $template ($template_cfg) ", 3 );
        print_log( "RRD Datatype is $dstype",                                 3 );
    }
 
#########################################
### Hier mal was brachial geändert
    print_log( "VORLAGE is $NAGIOS{VORLAGE}", 2 );
 
    if ($NAGIOS{VORLAGE} gt "" ) {
       $template = $NAGIOS{VORLAGE};
       }
    else {
       $template = $NAGIOS{SERVICEDESC};
       }
#########################################
    print_log( "Template is $template.php", 2 );
    $CTPL{'COMMAND'}           = $template;
    $CTPL{'TEMPLATE'}          = $template;

Nimmt man den „else“ Teil weg, funktioniert process_perfdata.pl wie gehabt im Auslieferungszustand. Ich habe als Fallback den Namen der Servicebeschreibung behalten … finde ich praktischer.

Und schon funktioniert das Ganze, ich brauche nur ein paar grundlegende Templates und kann meine Zeit in die „Spezial“ Templates stecken.