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.

Die schlechte Nachricht vorweg: Icinga2 benutzt eine neue Konfigurationssyntax! Es gibt natürlich tools zur Konvertierung, aber erstens traue ich solchen Tools nicht so recht und zweitens: Wenn ich schon etwas neu lernen muss, dann bitte gleich richtig. Also gehen wir im Folgenden von einer Icinga Neuinstallation aus. In den jeweiligen Kapiteln erkläre ich zunächst die Syntax an einem Beispiel und lege danach meine Koniguration offen.

• Hosts.conf
• Services.conf
• Groups

• Wetterdaten
• Kleine Icons

Wenn man check_apt einsetzt, was besonders bei Debian-Systemen sinnreich ist, wird man feststellen, dass check_apt keine Aktualisierungen anzeigt. Und das ist letztlich gefährlich!

Abhilfe: Vor dem Ausführen von Check_apt muss apt-get update ausgeführt werden. Ich helfe mir damit dass ich per Crontab morgens um sieben ein apt-get update ausführe. Danach zeigt apt-get korrekte Werte. Wer noch vorsichtiger sein will, kann das ja auch mehrmals am Tag tun.

Hinzu kommt noch etwas. Damit die Unterscheidung zwischen normalen Updates und kritischen Updates funktioniert, müssen die Security-Update in der Datei /etc/apt/sources.list als erstes stehen:

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
deb http://ftp.uni-kl.de/debian/ testing main contrib non-free
deb-src http://ftp.uni-kl.de/debian/ testing main contrib non-free  

Besonders meine liebe Frau litt unter Notifications-Spam, die von dern Wetterdaten kam. Ja, eine mail reicht wirklich!!!

Also fügen wir in notifications.conf die Zeile

  interval = 0      //disable re-notification

ein, und schon gibt es zu jedem Event nur noch eine Mail

Vorgaben: Wir gehen davon aus, dass Icinga2 und pnp4nagios bereits installiert sind und laufen (auch mit Datenbankanbindung) Ich habe mich entschieden Icinga-Web2 nach /usr/local/icingaweb2 zu installieren. Icinga-Web 2 benötigt zwingend eine Datenbank (entweder MySQL/Mariadb oder Postgres). Die Datenbank muss nicht auf dem gerade instalierten System liegen. (Bei mir ist dem so) Andernfalls muss man sie natürlich installieren

# Falls git noch nicht installiert sein sollte
apt-get install git
apt-get install php5 icinga2-ido-mysql 
 
git clone git://git.icinga.org/icingaweb2.git
mv icingaweb2 /usr/local/icingaweb2
./bin/icingacli setup config webserver apache --document-root /usr/local/icingaweb2/public

dabei wird der folgende Code erzeugt und angezeigt:

<code>
addgroup --system icingaweb2
usermod -a -G icingaweb2 www-dataAlias /icingaweb2 "/usr/local/icingaweb2/public"

<Directory "/usr/local/icingaweb2/public">
    Options SymLinksIfOwnerMatch
    AllowOverride None

    <IfModule mod_authz_core.c>
        # Apache 2.4
        <RequireAll>
            Require all granted
        </RequireAll>
    </IfModule>

    <IfModule !mod_authz_core.c>
        # Apache 2.2
        Order allow,deny
        Allow from all
    </IfModule>

    SetEnv ICINGAWEB_CONFIGDIR "/etc/icingaweb2"

    EnableSendfile Off

    <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteBase /icingaweb2/
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ index.php [NC,L]
    </IfModule>

    <IfModule !mod_rewrite.c>
        DirectoryIndex error_norewrite.html
        ErrorDocument 404 /error_norewrite.html
    </IfModule>
</Directory>

Dieser Code muss in /etc/apache2/conf.d/icingaweb2 kopiert werden.

a2enmod rewrite

./bin/icingacli setup config directory
./bin/icingacli setup token create
The newly generated setup token is: 738058896166a8f9

Den „Token“ müssen wir uns merken!

jetzt im Browser aufrufen http://ntech.selfhost.eu:8150/icingaweb2/setup

Den Setup-Token eingeben!

Die folgenden Konfigurations-Fragen sinngemäß richtig beantworten - Fertig!

Es könnte sein, dass man in der Datei /etc/php5/apache2/php.ini die Timezone setzen müssen.

date.timezone = Europe/Berlin

Folgende Pakete musste ich nachinstallieren:

apt-get install php5-gd php5-Imagick php5-intl php5-mysql

Fazit: die Installation geht erstaunlich leicht!

Wi egehen davon aus, dass Pnp4Nagios bereits fertig installiert ist und zuverlässig läuft. Dann muss nur die Integration von pnp4nagios in Icinga-Web 2 hergestellt werden.

Das Modul wird erst einmal angesaugt und richtig in das Modulverzeichnis von Icinga-Web2 verschoben:

git clone https://github.com/Icinga/icingaweb2-module-pnp4nagios.git
mv icingaweb2-module-pnp4nagios pnp4nagios
mv pnp4nagios /usr/local/icingaweb2/modules/

Anschließend muss man im Menu nach System → Modules navigieren und das Modul einschalten

Fertig! Einfach, oder?

Icingaweb2 erwartet die Daten über eine Datenbankverbindung, nämlich jene, die wir bereits bei der Installation von Icinga2 eingerichtet haben. Wenn nichts geht, sollte man /etc/icingaweb2/resources.ini prüfen:

[icingaweb_db]
type                = "db"
db                  = "mysql"
host                = "localhost"
port                = "3306"
dbname              = "icingaweb2"
username            = "icinga"
password            = "********"
prefix              = "icingaweb_"


[icinga_ido]
type                = "db"
db                  = "mysql"
host                = "localhost"
port                = "3306"
dbname              = "icinga2"
username            = "icinga"
password            = "********"

Apache 2.4 war auf dem system bereits installiert (Nur als Anmerkung)

apt-get install icinga2 db_ido_mysql

Die Debian-Installationroutine fragt nach einer Datenbankverbindung. Dabei kann man aber nur eine lokale Datenbank konfigurieren. Wenn man's genauer haben will, oder eine abgesetzte Datenbank hat, findet man die Details in /etc/icinga2/features-available/ido-mysql.conf object IdoMysqlConnection "ido-mysql" { user = "icinga", password = "********", host = "localhost", database = "icinga2" }

anschliessend kann man mit icinga feature enable ido-mysql die Datenverbindung starten.

die Verarbeitung von Performance-Daten wird mit icinga feature enable perfdata eingeschaltet. Aber Vorsicht: das habe ich versucht und erst viel später pnp4nagios installiert, welches ja die Performancedaten übernimmt und weiterverarbeitet. Bis dahin hatten sich ein paar hunderttausend Dateien angesammelt und das System war für Stunden mit sich selbst beschäftigt.

Besser ist es, erst pnp4nagios zu installieren und dann perfdata einzuschalten.

Mir stand bereits eine weitgehend vollständige Konfiguration von einem Testsystem zur Verfügung, die ich nur umkopieren musste. Aber keine Angst, auf die Konfiguration werde ich noch eingehen. Mehr als mir lieb ist!

root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/commands.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/hosts.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/services.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/nrpe-services.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/hoss-services.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/eazy-services.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/printer-services.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/wetter-services.conf .
root@icinga:/etc/icinga2/conf.d# scp poenix:/etc/icinga2/conf.d/ssh-services.conf .

Aus irgendwelchen Gründen sind zunächst keine SNMP-Checks möglich. Um diese zu aktivieren, muss in die Datei /etc/icinga2/icinga2.conf eine Zeile eingefügt werden:

include <manubulon>

Ich arbeite gern mit Perl, etliche Checks sind damit geschrieben. Daher müssen für Perl einige Module nachinstalliert werden … dafür sind auch die Build-Essentials nötig

apt-get install build-essential
perl -MCPAN -e shell
install Net::SMTP