Wir möchten einen Server haben, der unser Netzwerk und unsere Services überwacht und ggf. einen Überblick über den Status ausgibt sowie uns im Notfall auf dem Handy alarmiert, wenn etwas wichtiges nicht läuft. Hierzu haben wir uns [https://www.icinga.org/ Nagios] und [https://www.icinga.org/ Icinga] angesehen und uns letztlich für letzteres entschieden.


!!! Basissystem

Als Basis habe ich auf einem ausrangierten Netbook ein [http://www.debian.org Debian] Jessie (Testing Version Juli 2013) installiert. Debian Linux benutzt als Paketmanager das Programm "aptitude", das es erlaubt, einzelne Pakete mitsamt ihren Abhängigkeiten zu installieren oder zu deinstallieren.

Als Zusatz habe ich wie immer '''joe''' installiert. Außerdem bietet sich je nach Netzwerkzugang das Paket '''resolvconf''' an.

 aptitude install joe resolvconf

!! Netzwerkkonfiguration

Da der Monitoring-Rechner möglichst viele Aspekte des Netzes testen soll aber gleichzeitig von diesem nicht abhängig sein sollte, konfiguriere ich drei mögliche Netzwerkverbindungen: Ein Netzwerkkabel (eth0), ein WLAN (wlan0) und eine Verbindung über einen UMTS-Stick (ppp0).

...to be done

!! Jabber

Die Kommunikation mit der Außenwelt, insbesondere mit einem Mobiltelefon, soll über das [http://www.jabber.org XMPP (Jabber)] Protokoll stattfinden.

...to be done

vorläufige Linkliste zum Thema:
* http://www.lug-wr.de/wiki/index.php/UMTS
* http://wiki.debian.org/Wvdial
* http://www.lug-kr.de/wiki/Monitoring.Icinga
* http://www.lug-kr.de/wiki/MobilesInternet
* http://superuser.com/questions/225327/how-can-i-get-wvdial-to-run-from-etc-network-interfaces
* http://manpages.debian.net/cgi-bin/man.cgi?sektion=5&query=interfaces&apropos=0&manpath=sid&locale=en
* http://linux.die.net/man/5/wvdial.conf
* http://wiki.siduction.de/index.php?title=UMTS/GPRS_Internet_Zugang_erstellen_mit_Hilfe_von_wvdial
* http://www.eric-scheibler.de/ericsblog/blog/2012/04/09/Verwenden-des-UMTS-Modems-Huawei-E160-unter-Debian-Squeeze/


!!! Installation

Ich möchte nicht nur das "nackte" Icinga nutzen, sondern auch die neue, erweiterte Web-Oberfläche. Diese ist im Paket "icinga-web" enthalten. Die klassische Oberfläche ist im Paket "icinga-cgi" enthalten. Will man beide gleichzeitig installieren, ergibt sich ein Konflikt zwischen den zwei empfohlenen Varianten des [http://www.apache.org Apache Webserver]. Deshalb kommt noch das Paket '''apache2-mpm-prefork''' hinzu. Des weiteren möchte ich gerne meine Datenbank in einem PostgreSQL-Server und nicht in MySQL haben, weswegen ich noch einige Pakete bzgl. der Anbindung an PostgreSQL hinzugefügt habe:

 aptitude install icinga icinga-web apache2-mpm-prefork postgresql php5-pgsql libdbd-pgsql postgresql-client

Bei der Installation werde ich (für das Paket "icinga-cgi", wie man im Titel des Fensterchens sehen kann) nach dem Passwort für den Benutzer ''icingaadmin'' gefragt. Das ist der Benutzer, mit dem ich mich später in die klassische Weboberfläche unter http://inicinga.bayen.loc/icinga einloggen kann.

Für das "icinca-ido" Paket werde ich nach einem Datenbank-Passwort gefragt. Ich richte die Datenbank in PostgreSQL automatisch durch die Debian-Installationsskripte (und nicht manuell) ein und vergebe hier ein Passwort (meins ist leicht ähnlich dem vorhergehenden).

Danach wurde ich nach dem Passwort (für das Paket "icinga-web") für den Benutzer "root" gefragt. Hier kann man ggf. wieder ein ähnliches Passwort wie gerade (oder ein ganz anderes) verwenden. Dieses gilt dann für die neue Weboberfläche unter http://icinga.bayen.loc/icinga-web.

Es erscheint eine Frage, ob ich externe Befehle benutzen möchte. Dies wird als ein potentielles Sicherheitsrisiko beschrieben. Da ich hiermit erst einmal experimentieren möchte, erlaube ich es dennoch.

Aus mir nicht ganz nachvollziehbaren Gründen ergab die "modernere" Oberfläche unter /icinga-web keine Anzeige. Nach ein bisschen Suchen und lesen sah ich in der Debian.README-Datei zum Paket icinga-idoutils, das man ein Icinga-Modul aktivieren muss, damit Icinga per ido Daten in die Datenbank schreibt. Meiner Meinung nach sollte das bei der Paketinstallation von selber so eingerichtet werden, wird es aber nicht... Das habe ich dann mit folgendem Befehl nachgeholt:

 cp /usr/share/doc/icinga-idoutils/examples/idoutils.cfg-sample /etc/icinga/modules/idoutils.cfg

Im Icinga-Web waren alle Zeitangaben in der falschen Zeitzone (GMT anstatt CEST). Das konnte ich beheben wie auf http://www.monitoring-portal.org/wbb/index.php?page=Thread&threadID=24741 beschrieben (ist zwar IMHO nicht ganz sauber, weil es im Server geändert wird und nicht in der Applikation, aber für mich läufts so).

!!! Konfigurationsdateien

Grundsätzlich stehen alle Konfigurationen im Verzeichnis '''/etc/icinga/objects/''' in Dateien mit der Endung ".cfg". Im Prinzip ist auch egal, was wir hier in welche Datei schreiben. Für mich sieht es sinnvoll aus, für jeden Host im Netzwerk, den ich überwachen will, eine Datei anzulegen. In dieser Datei definiere ich dann den Host sowie alle auf diesem host ablaufenden Services.

Neue Kommandos definiere ich zentral in der Datei '''commands.cfg''', um diese nur einmal zentral zu verwalten. Viele Kommandos sind übrigens bereits von den Debian-Paketen vorkonfiguriert. Diese command-Definitionen stehen in '''/etc/nagios-    plugins/config/'''.


!!! Neuen Host anlegen

Ich erzeuge im Verzeichnis '''/etc/icinga/objects/''' für den Host "krefix" eine Datei "krefix.cfg". Dort schreibe ich als erstes folgendes hinein:

 define host{
       use                     generic-host
       host_name               krefix
       alias                   Krefix Router
       address                 192.168.2.1
 }

Damit die Änderung an der Konfiguration gültig wird, muss noch der Icinga-Server neu gestartet werden:

 invoke-rc.d icinga restart

Auf der Weboberfläche kann man nun bereits sehen, ob dieser Host (per Ping) erreichbar ist.


!!! Services anlegen

Nun schreibe ich in die Datei des Hosts weitere Einträge für die Services, die dieser Host bietet:

 define service{
       use                     generic-service
       host_name               krefix
       service_description     DNS Nameserver intern
       check_command           check_dig!krefix
 }

Bei "check_dig" handelt es sich um ein "command". Dieses ist bereits vordefiniert. Manche Commands sind durch die Debian-Pakete vordefiniert, andere muss man selber noch definieren (z.B. in der Datei commands.cfg, siehe unten).

Im folgenden beschreibe ich einige Services, die ich eingerichtet habe:

!! DHCP

Damit ein DHCP-Server getestet werden kann, muss ein command definiert werden (z.B. in der Datei '''commands.cfg''').

 define command{
               command_name            check_dhcp_service
               command_line            $USER1$/check_dhcp -i eth0
 }

Dann geht es aber immer noch nicht, weil der hierin benutzte Befehl '''check_dhcp''' nämlich root-Rechte benötigt:

 chmod a+s /usr/lib/nagios/plugins/check_dhcp

Die entsprechende Service-Definition sieht folgendermassen aus:

 define service{
       use                     generic-service
       host_name               krefix
       service_description     DHCP-Server
       check_command           check_dhcp_service
 }


!!! Gruppieren von Einträgen

Es gibt zwei Systeme, um Host-Einträge zu gruppieren. Zum einen kann man host-Eigenschaften mit "use" vererben. Das ist sinnvoll, um Einträge in der host-Definition nur einmal schreiben zu müssen. Ein Beispiel hierfür kann z.B. die Definition von Bildern für das angezeigte Icon sein. Das sieht dann beispielsweise so aus:

 define host{
       name            laptop
       icon_image      didier/Laptop.png
       vrml_image      didier/Laptop.png
       statusmap_image didier/Laptop.png
       notes           Laptop-Rechner
       register        0
 }
 
 define host{
       use             laptop
       name            meinrechner
       alias           meinrechner
       address         192.168.2.50
       ...
 }

Diese Art, Eigenschaften durch Vererbung zu gruppieren, geht auch mit anderen Objekttypen als nur mit Hosts. Näheres hierzu findet sich natürlich am besten in der [http://docs.icinga.org/1.9/de/objectdefinitions.html#host Icinga-Anleitung zu Objektdefinitionen].

Eine andere Form von Gruppierungen kann man über den Eintrag hostgroups erreichen. Hier wird eine Gruppe einmal definiert. Dann kann man einzelne Hosts in diese Gruppe aufnehmen. Diese Gruppierung kann dann später z.B. in einer Auswertung benutzt werden, d.h. icinga-web erlaubt einem, alle Hosts einer bestimmten Abteilung in einer Liste anzuzeigen. Beispiel:

 define hostgroup{
       hostgroup_name  abteilung1
 }
 
 define host{
       use             laptop
       name            meinrechner
       alias           meinrechner
       address         192.168.2.50
       hostgroups      abteilung1
       ...
 }

!!! Bilder vergeben

Für die beiden Web-Oberflächen kann man für die Hosts kleine Bilder als Icons auswählen. In der Debian-Standardinstallation liegen diese im Verzeichnis
''/usr/share/nagios/htdocs/images/logos/'' in verschiedenen Unterverzeichnissen je nach der Quelle der Files. Die Einträge für die Bilder können ganz gut von einer einheitlichen Host-Definition abgeleitet werden (wie oben im Beispiel für die Gruppierungen geschehen).

!!! Notifications

Bis hierhin kann unser Icinga auf der Weboberfläche schön anzeigen, welche Hosts und Services laufen und welche nicht. Schön wäre jetzt natürlich, wenn man diese Weboberfläche nicht den ganzen Tag anstarren muss, sondern automatisch informiert würde, wenn im Netzwerk etwas schiefgeht. Dazu dienen Notifications.

In der Standard-Konfiguration ist in der Definition für "generic-hosts" (in der Datei "generic-host_icinga.cfg"), von der alle Hosts abgeleitet werden, vorgegeben, das im Falle einer Notification alle Kontakte informiert werden, die in der Gruppe "admin" versammelt sind. Das kann man natürlich ändern, aber wir nehmen das erst einmal so hin und wollen nun für uns selbst einen Kontakt definieren, der dann Mitglied dieser Gruppe sein soll.

...to>> << definebe>> <<contact{continued>>
<<        contact_name                    tbayen
<<        alias                           Thomas Bayen
       service_notification_period     24x7
       host_notification_period        24x7
       service_notification_options    w,u,c,r
       host_notification_options       d,r
       service_notification_commands   notify-service-by-jabber
       host_notification_commands      notify-host-by-jabber
       pager                           bayen@jabber.org
       contactgroups                   admin
 }

Die Notification per EMail ist in allen Beispielen ausreichend erklärt, deshalb stelle ich hier eine Lösung per Jabber vor. Dazu habe ich das Debian-Paket "sendxmpp" installiert und die folgenden Kommandos definiert:

 define command{
   command_name  notify-host-by-jabber
   command_line  echo '$SHORTDATETIME$ $HOSTNAME$ $HOSTSTATE$/$NOTIFICATIONTYPE$: $HOSTOUTPUT$' | /usr/bin/sendxmpp -f /etc/icinga/sendxmpprc $CONTACTPAGER$
 }

 define command{
   command_name notify-service-by-jabber
   command_line echo '$SHORTDATETIME$ $HOSTNAME$/$SERVICEDESC$ $SERVICESTATE$/$NOTIFICATIONTYPE$: $SERVICEOUTPUT$' | /usr/bin/sendxmpp -f /etc/icinga/sendxmpprc $CONTACTPAGER$
 }


!!! Icinga-Werte mit Conky auf den Desktop beamen

Wieso entdecke ich diese spannende Seite erst jetzt?\\
__Danke an Thomas für die ausführliche Anleitung.__\\
Hier ein paar Notizen meiner Gehversuche mit Icinga und Conky.
(Markus Monderkamp, 23.07.2013)

Ist Icinga erst einmal soweit konfiguriert, bietet sich das Zeichnen seiner Sensorenwerte auf den Desktop an.

sudo aptitude install conky

Dann:
* https://github.com/visibilityspots/scripts : \\ "script can be used to display the output of icinga on your desktop conky setup. \\ Usage in conkyrc configfile: ${execpi 53 PATH/TO/conky-icinga.sh}"
* https://github.com/arioch/scripts/blob/master/conky-icinga.sh : "Scripts written for making daily life more comfortable"
* http://www.visibilityspots.com/conky-colors.html : Farben, Icinga und Conky

Eine geschmackvollere Ausgabe erzeugt laut c't Linux Spezial Magazin die Conky-Konfiguration aus Reloj Conky (http://votritis.deviantart.com/art/Reloj-Conky-208415121).
Granular einstellen lässt sich Conky u.a. für Icinga mit ~ConkyWizard (http://code.google.com/p/conkywizard/).
Weitere Infos zu Conky liefert auch die betreffende Linksammlung aus der c't: http://www.heise.de/ct/special/13/02/links/086.shtml .

!!! ältere Version dieses Artikels (ca. aus 2011)

[Icinga|http://www.icinga.org] ist ein inzwischen ordentlich verbesserter Fork von [Nagios|Monitoring.Nagios].

!! Installation

! Basissystem

Ich habe Nagios auf einem dedizierten, akkugestützten System installiert (sprich: auf einem eigenen, preiswerten Netbook), auf dem am besten sonst nichts anderes läuft. Es sollte tunlichst vermieden werden, daß dieses System von irgendwelchen anderen Problemen in Mitleidenschaft gezogen werden kann (schließlich ist der Monitoring-Dienst der einzige, der nicht vom Monitoring überwacht werden kann...), daher sollte es möglichst autark sein. Später werde ich ihm dazu noch einen eigenen UMTS-Stick (für einen Internet-Zugang und SMS-Meldungen) spendieren.

Zur Installation auf einem Debian Squeeze Basissystem habe ich folgendes gemacht:

Da ich eine aktuelle Icinga-Version einspielen möchte, habe ich (nach einem normalen upgrade) die [Squeeze Backports|http://backports-master.debian.org/Instructions/|squeeze-backports] eingebunden.

! Icinga

 aptitude install postgresql
 su postgres
 pgsql
     create language plpgsql;
 \d
 \d
 aptitude -t squeeze-backports install icinga
 aptitude -t squeeze-backports install icinga-docs icinga-idoutils



! Commandfile freigeben

Icinga kann über ein sogenanntes Command File gesteuert werden. Das benutzt insbesondere die Weboberfläche, um Befehle, z.B. für einen Reschedule zu geben. Diese Schnittstelle muss aber zuerst freigegeben werden:

In ''/etc/icinga/icinga.cfg'' ändern:
 
 check_external_commands=1

Nun gibt es aber noch ein anderes Problem: In der Standard-Debian-Installation hat die Weboberfläche keinen Zugang zum Commandfile ''/var/lib/icinga/rw.icinga.cmd''.

Laut dem an sonsten recht hilfreichen Artikel http://suckup.de/2010/09/26/icinga/ kann man mit "dpkg-statoverride" die Zugriffsrechte dauerhaft (auch Paketupdate-übergreifend) ändern.

 dpkg-statoverride --update --add nagios www-data 660 /var/lib/icinga/rw/icinga.cmd

Leider fehlt dort erstens der Hinweis, das man auch ein "x"-Recht für das "rw"-Verzeichnis braucht und zweitens blieben bei mir die Zugriffsrechte immer genau so lange bestehen, bis ich den Icinga-Server neu gestartet habe. :-(

Also habe ich mir das Problem nochmal betrachtet und stttdessen den Webserver in die Nagios-Gruppe aufgenommen:

 addgroup www-data nagios



! Icinga-Web

Bis hierhin komme ich erst mal so weit, das die klassische Weboberfläche unter http://monitorserver/icinga läuft. Leider gibt es für die neue, viel hübschere Weboberfläche __Icinga Web__, die für mich ein wichtiger Grund war, mich für Icinga und gegen Nagios zu entscheiden, kein Debian Paket.

Hier steht beschrieben, wie man icinga-web aufsetzt, für das es scheinbar noch kein Debian-Paket gibt:
* https://wiki.icinga.org/display/howtos/Setting+up+Icinga+Web+on+Debian

...ich werde hier also weiter berichten.


! SMS-Versand

Ich habe mein Skript zum [SMSVersand] nach "/root" installiert, es ausführbar gemacht und benutze dieses dann aus den Icinga-Konfigurationen heraus.

 aptitude install groovy

 scp smsversand.groovy root@monitorserver:.



!! Ergebnis bis hierhin

Bis hierhin komme ich erst mal so weit, das die klassische Weboberfläche unter http://monitor/icinga läuft.



----
[{Tag Linux Debian Monitoring ServerDienste}]