In diesem HowTo zeige ich wie du einen Monitoring-Server mit Icinga aufsetzt, dazu folgen einige Beispiele und eine optimierte Konfiguration.
Was ist Icinga?
Icinga ist ein “Fork” des wohlbekannten Überwachungssystems Nagios. Eine 100%ige Kompatibilität mit den internen Strukturen des letzteren erlaubt es Ihnen, mit Icinga alle Plugins und Addons zu benutzen, die von verschiedenen Firmen und der großen Community entwickelt wurden bzw. werden. Der Icinga-Dienst selbst läuft als eigenständiger Prozess mit eingeschränkten Rechten auf dem Server und lässt sich über die textbasierenden Konfigurationsdateien konfigurieren. Zudem läuft ein Web-Server (Apache2 + mod_cgi + mod_php5), um auf CGI basierende Web-Schnittstelle zum Abfragen der gesammelten Daten zuzugreifen. Wer bereits jetzt einen Blick auf die Software werfen will, sollte sich die Demo (User: guest, Passwort: guest) anschauen.
Windows-Server: Für das Monitoring von Windows-Servers kannst du die Software “NSClient++” einsetzten, in welcher nur das NRPE-Modul aktiviert werden muss, so dass Abfragen (Checks) serverseitig mit eingeschränkten Rechten ausgeführt werden und vom Monitoring-Server abgefragt werden können.
Linux-Server: Auch bei den Linux-Servern kommt ein NRPE-Server zum Einsatz, welcher die Abfragen (Checks) ebenfalls lokal ausführt und die Ergebnisse dem Monitoring-Server zur Verfügung stellt. Im laufe des HowTos, werde ich noch zeigen, wie man diesen installiert und konfiguriert.
SNMP: Einige Netzwerkkomponenten z.B. der Datendurchsatz von einigen Netzwerk-Schnittstellen, Temperaturwerte u.s.w. … können mittels SNMP abgefragt werden. Für diesen Zweck werden noch einige Erweiterungen (Plugins) für Icinga installiert.
Welches Betriebssystem?
In meinen Test nutze ich “Debian” in der aktuellen Version mit dem Codenamen “Lenny” . “Icinga” liegt in den nun offiziellen Backports bereits als vorkompiliertes Paket in den Softwarequellen vor und kann daher leicht installiert und aktualisiert werden.
Vorbereitung der Umgebung
Betriebssystem
Ich nutze eine Standard Distribution von Debian (Lenny) mit minimalen vorinstallierten Anwendungen. Die Distribution bringt ein breites Spektrum am Software mit, so dass als erstes ein SSH-Server (openssh-server), Mailserver (postfix) und ein Webserver (apache2) nachinstalliert wurden. Wer sich mit der Paketverwaltung von Debian noch nicht so gut auskennt, sollte sich zuvor folgenden Post-Post durchlesen: suckup.de/blog/2010/02/13/aptitude-dpkg/
Monitoring-Server
Die Installation von Icinga wird über die Paketverwaltung des Betriebssystems realisiert, dazu müssen jedoch die zuvor erwähnten Backports mit im System aufgenommen werden.
echo 'deb http://backports.debian.org/debian-backports lenny-backports main' >> /etc/apt/sources.list
echo 'Package: *' >> /etc/apt/preferences
echo 'Pin: release a=lenny-backports' >> /etc/apt/preferences
echo 'Pin-Priority: 200' >> /etc/apt/preferences
apt-get updat
Installiert wurden die folgenden Pakete und dessen Abhängigkeiten.:
aptitude install icinga icinga-doc nagios-snmp-plugins nagios-nrpe-plugin
[stextbox id=”warning”]Hinweis: Bitte darauf achten, dass Nagios3 nicht mit installiert wird, da dies vom nagios-nrpe-plugin empfohlen wird.[/stextbox]
Die Pakete „nagios-plugins“, „nagios-plugins-standard“ – die Nagios-Plugins werden ebenfalls automatisch als Abhängigkeit per Paketverwaltung installiert, und werden bei Ininga automatisch in der folgenden Konfigurations-Datei integriert.
Konfiguration von Icinga
Als erstes zeige ich anhand von einem Schaubild, wie die Konfiguration später aussieht. In dem Schaubild sind jedoch nicht alle Konfigurations-Dateien vorhanden, dies dient nur der Veranschaulichung.
Hauptkonfigurationsdatei: icinga.cfg
In der Hauptkonfigurationsdatei werden Basisparameter der Monitoring-Software festgelegt. Da bereits die Nagios-Plugins, dass heißt die einzelnen Prüf-Programme (Checks) für z.B. SSH, SMTP, FTP u.s.w. über die Paketverwaltung des Betriebssystems installiert wurden, wurden die bereits mit folgender Zeile mit aufgenommen.
cfg_dir=/etc/nagios-plugins/config/
Des-weiteren gibt die nächste Zeile an, welches Verzeichnis von Icinga rekursiv nach Dateien, welche auf .cfg enden, durchsucht wird, so dass weitere Konfigurations-Dateien einfach angelegt werden können.
cfg_dir=/etc/icinga/objects/
Bisher haben wir noch nichts an der Konfiguration geändert, ich habe die angesprochen Zeilen nur erwähnt, um die Konfiguration besser verstehen zu können. Aus dem selben Grund, stelle ich hier einmal kurze die Verzeichnisstruktur (tree) der Konfiguration dar.:
|– cgi.cfg
|– commands.cfg
|– objects
| |– contact
| | |– contactgroups.cfg
| | |– contacts.cfg
| | `– contacts_templates.cfg
| |– hosts
| | |– intern
| | | |– linux_server.cfg
| | | |– windows_server.cfg
| | | |– drucker.cfg
| | | `– […]
| | |– host_templates.cfg
| | |– hostextinfo.cfg
| | |– hostgroups.cfg
| | |– kunden
| | | |– kunde1.cfg
| | | |– kunde2.cfg
| | | `– […]
| |– services
| | |– services_host.cfg
| | `– services_templates.cfg
| `– timeperiods.cfg
|– htpasswd.users
|– icinga.cfg
|– resource.cfg
[stextbox id=”info”]Tipp: Um über die Weboberfläche per CGI Befehle auszuführen, müssen wir “check_external_commands” von “0” auf “1” umstellen und dem Webserver (CGI) die Rechte auf folgende Datei geben.[/stextbox]
check_external_commands=1
dpkg-statoverride --update --add nagios www-data 660 /var/lib/icinga/rw/icinga.cmd
CGI-Konfigurationsdatei: cgi.cfg
In dieser Datei werden die Zugriffsrechte für die zuständigen Benutzer und einige Einstellungen bezüglich der Weboberfläche festgelegt.
Kommando-Konfigurationsdatei: commands.cfg
Alle Abfragen welche nicht bereits mit den Nagios-Plugins installiert wurden, z.B. speziell entwickelte Skripte oder Kommandos zum Senden von SMS / E-Mails werden in dieser Datei definiert.
cd /etc/icinga/
wget http://suckup.de/commands.txt
mv commands.txt commands.cfg
Objekt-Konfigurationsdateien: objects/*.cfg
Kommen wir zur Host- / Servicekonfiguration und dessen Verzeichnisstruktur, um mit Vorlagen und Vererbungen zu arbeitet, gehen wir wie folgt vor.:
[stextbox id=”warning”]Bitte nicht einfach alle Befehle nacheinander per “Copy&Past” einfügen, überlege was du tust und falls du bereits etwas an Icinga konfiguriert hast, sicher diese Datei vorher!!![/stextbox]
cd /etc/icinga/objects/
rm *.cfg
wget http://suckup.de/timeperiods.txt
mv timeperiods.txt timeperiods.cfg
rm timeperiods_icinga.cfg
mkdir contact/ doc/ hosts/ services/
rm extinfo_icinga.cfg generic-host_icinga.cfg generic-service_icinga.cfg hostgroups_icinga.cfg localhost_icinga.cfg services_icinga.cfg contacts_icinga.cfg
cd contact/
wget http://suckup.de/contacts_templates.txt
mv contacts_templates.txt contacts_templates.cfg
wget http://suckup.de/contacts.txt
mv contacts.txt contacts.cfg
wget http://suckup.de/contactgroups.txt
mv contactgroups.txt contactgroups.cfg
cd ..
[stextbox id=”info”]Tipp: In der Datei „contacts.cfg“ kannst du nun neue User eintragen und diese in der Datei „contactgroups.cfg“ zu einer Gruppe zusammenfassen.[/stextbox]
cd hosts/
mkdir intern/ kunden/
wget http://suckup.de/host_template.txt
mv host_template.txt host_template.cfg
wget http://suckup.de/hostgroups.txt
mv hostgroups.txt hostgroups.cfg
[stextbox id=”info”]Tipp: In der Datei „hostgroups.cfg“ werden den Hostgruppen z.B. allen Windows-Server bestimmte Services zugeordnet, so dass in der Hostkonfiguration [intern/ und kunden/] nur noch die Hostgruppe zugeordnet werden muss, um alle zugeordneten Services zu checken.[/stextbox]
wget http://suckup.de/hostextinfo.txt
mv hostextinfo.txt hostextinfo.cfg
[stextbox id=”info”]Tipp: Um die „alte“ hostmap zu verwalten, kann man sich folgendes kleine Perl-Skript herunterladen, damit hat man eine GUI in der man die bereits eingetragenen hosts auf der Karte positionieren kann. Einfach mal bei google nach „nagios-2d-editor“ suchen.[/stextbox]
cd intern/
wget http://suckup.de/switch.txt
mv switch.txt switch.cfg
wget http://suckup.de/linux_server.txt
mv linux_server.txt linux_server.cfg
cd ..
cd kunden/
wget http://suckup.de/kunde1.txt
mv kunde1.txt kunde1.cfg
cd ../../services/
Die hier zur Verfügung gestellten Dateien (hostextinfo.cfg, switch.cfg, linux_server.cfg, kunde1.cfg) müssen natürlich noch angepasst, werden (Hostnamen, Domain, Kunden-Name, IP-Adresse, Abhängigkeiten…) und halten einzig der Veranschaulichung der Konfiguration her. :-)
wget http://suckup.de/services_templates.txt
mv services_templates.txt services_templates.cfg
wget http://suckup.de/services_host.txt
mv services_host.txt services_host.cfg
Auch die hier zur Verfügung gestellt Datei (services_host.cfg) muss im Produktiv-System noch angepasst werden, weitere hilfreiche Tipps befinden sich als Kommentare in den Dateien selbst.
Wer bisher jeden Host und Service komplett in die „hosts.cfg“ und „services.cfg“ geschriben hat, kann mit der zuvor erklärten Methode zirka 90% der Konfiguration einsparen, zudem wird das ganze übersichtlicher und es schleichen sich weniger Fehler ein.
[stextbox id=”info”]Tipp: Wenn du das Passwort, welches du bei der Installation angegeben hast, vergessen solltest, kannst du es per “htpasswd” neu setzten und auch neue User anlegen, dazu musst du neuen Usern die passenden Rechte in der “cgi.cfg”-Datei zuweisen .[/stextbox]
Nagios-Plugins
Damit Icinga in der Lage ist Server (Dienste) und andere Ressourcen zu überprüfen, wurden die verschiedene Plugins bereits bei der Vorbereitung der Monitoring-Umgebung installiert, jedoch fehlten ggf. noch Plugins welche wir zusätzlich verwenden möchten, um diese mit in die Konfiguration auszunehmen, gehen wir wie folgt vor.:
1.) In dem folgendem Verzeichnis legen wir das Check-Programm ab…
cd /usr/lib/nagios/plugins/
2.) Tragen das dazu passende Kommando in dieser Datei ein…
vim /etc/icinga/commands.cfg
3.) Fügen ggf. eine neue Gruppe hinzu oder nutzen eine bestehende und fügen den ensprechenden Service_Check hinzu…
vim /etc/icinga/objects/hosts/hostgroups.cfg
4.) Nun können wir die Gruppe in allen Hosts verwenden…
vim /etc/icinga/objects/hosts/[intern|kunden]/*.cfg
Performancedaten darstellen: PNP
Als nächstes wollen wir einige Performance-Daten visuell darstellen, dafür installieren wir PNP4NAGIOS. Wie dieses Programm funktioniert findest du weiter unten…
Einige Abhängigkeit wurden als erstes nachinstalliert.
aptitude install g++ make php5 php5-gd rrdcollect rrdtool librrdp-perl librrds-perl
Als nächstes wurde der Quellcode heruntergeladen, entpackt und für das laufende System konfiguriert.
cd /usr/src/
VERSION=0.6.6
wget http://downloads.sourceforge.net/project/pnp4nagios/PNP-0.6/pnp4nagios-$VERSION.tar.gz
tar -xvzf pnp4nagios-$VERSION.tar.gz
cd pnp4nagios-$VERSION
./configure
Danach wurden die in C geschriebenen Komponenten kompiliert.
make all
Und mit dem folgenden Befehlen wurden die Dateien (Programm, Konfiguration, zusätzliche Webserver-Konfiguration…) an die passende Stelle im Dateisystem kopiert.
make install && make install-webconf && make install-config && make install-init
Die Software wurde nun noch in Icinga integriert, dafür muss die “icinga.cfg“-Datei wie folgt angepasst werden.
# Performance-Daten aktivieren
process_performance_data=1
# Service Performance-Daten
service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file
# Host Performance-Daten
host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file
In der “commands.cfg” Konfiguration müssen zudem zwei neue Kommandos eingefügt werden, sofern diese nicht bereits vorhanden sind.
define command{
command_name process-service-perfdata-file
command_line /bin/mv /usr/local/pnp4nagios/var/service-perfdata /usr/local/pnp4nagios/var/spool/service-perfdata.$TIMET$
}
define command{
command_name process-host-perfdata-file
command_line /bin/mv /usr/local/pnp4nagios/var/host-perfdata /usr/local/pnp4nagios/var/spool/host-perfdata.$TIMET$
}
mv /usr/local/pnp4nagios/etc/npcd.cfg-sample /usr/local/pnp4nagios/etc/npcd.cfg
mv /etc/httpd/conf.d/pnp4nagios.conf /etc/apache2/conf.d/pnp4nagios.conf
In folgender Datei muss der Pfad zur passwd-Datei bearbeitet werden:
vim /etc/apache2/conf.d/pnp4nagios.conf
AuthUserFile /etc/icinga/htpasswd.users
rmdir /etc/httpd/conf.d && rmdir /etc/httpd/ && apache2ctl restart
[stextbox id=”info”]Tipp: Um nun zu prüfen, ob alle Voraussetzen erfüllt sind, rufen wir einfach die entsprechend Webseite auf: z.B.: http://icinga.test.de/pnp4nagios/[/stextbox]
Schlussendlich wird PNP mit folgender Konfigurationszeile in einer Host-Definition bzw. dessen Vorlage in die Weboberfläche integriert:
action_url /pnp/index.php?host=$HOSTNAME$&srv=$SERVICEDESC$
Quelle: (3)
PNP4nagios Funktionsweise
PNP wird wie bereits zuvor beschrieben im Bulk-Modus (mit NPCD) betrieben. Dies bedeutet, dass die Performance-Daten in einem Verzeichnis gesammelt werden und dann von dem NPCD (Nagios Performance Data C Daemon) Dienst verarbeitet werden. Gegenüber dem Standard-Modus hat dieser den entscheidenden Vorteil, dass das Programm zur Verarbeitung der Performance-Daten nicht bei jeder Überprüfung (Check) ausgeführt werden muss und somit Systemressourcen eingespart werden.
Quelle: (3)
Monitoring-Client
Der „Nagios Remote Plugin Executor“ (NRPE) wird benötigt, um lokale Ressourcen auf den zu überwachenden Servern für den Nagios-Server bereitzustellen. Der NRPE-Dienst führt diese Überprüfungen wiederum über lokale Plugins aus. Unter Debian kann man den NRPE-Server mit folgendem Befehl installieren:
aptitude install nagios-nrpe-server nagios-plugins nagios-plugins-basic
Nun geben wir noch an, welche IP-Adresse auf die Daten zugreifen darf, also die IP-Adresse vom Monitoring-Server.
vim /etc/nagios/nrpe.cfg
allowed_hosts=X.X.X.X
Einige Kommandos sind bereits in der Datei nrpe.cfg definiert, diese Kommentieren wir jedoch nun aus und schreiben alle unsere Kommandos in die folgende Datei.
vim /etc/nagios/nrpe_local.cfg
z.B.:
# check system
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200
command[check_syslog]=/usr/lib/nagios/plugins/check_procs -C syslogd -c 1:1
command[check_retro]=/usr/lib/nagios/plugins/check_procs -C retroclient -w 1:20 -c 1:20
command[check_process]=/usr/lib/nagios/plugins/check_procs -C process.pl -w 1:1 -c 1:1
command[check_mailq]=/usr/lib/nagios/plugins/check_mailq -M postfix -w 250 -c 1000
command[check_procs]=/usr/lib/nagios/plugins/check_procs -w 250 -c 300
command[check_cron]=/usr/lib/nagios/plugins/check_procs -C cron -w 1:20 -c 1:20
command[check_bacula-fd]=/usr/lib/nagios/plugins/check_procs -C bacula-fd -w 1:1 -c 1:1
command[check_freshclam]=/usr/lib/nagios/plugins/check_procs -C freshclam -w 1:1 -c 1:1
command[check_amavisd]=/usr/lib/nagios/plugins/check_procs -u amavis -a amavisd -w 2:4 -c 1:5
command[check_clamd]=/usr/lib/nagios/plugins/check_procs -C clamd -w 1:5 -c 0:6
command[check_mysql]=/usr/lib/nagios/plugins/check_mysql -H 127.0.0.1 -u nagios -p test123
command[check_ssh]=/usr/lib/nagios/plugins/check_ssh -H 127.0.0.1
command[check_amavis_port]=/usr/lib/nagios/plugins/check_tcp -H 127.0.0.1 -p 10025
command[check_spamd]=/usr/lib/nagios/plugins/check_procs -C spamd -c 1:10
# check disks
command[check_disk_root]=/usr/lib/nagios/plugins/check_disk -w 1000 -c 750 -p /
command[check_disk_tmp]=/usr/lib/nagios/plugins/check_disk -w 200 -c 100 -p /tmp
command[check_disk_var]=/usr/lib/nagios/plugins/check_disk -w 1000 -c 750 -p /var
command[check_swap]=/usr/lib/nagios/plugins/check_swap -w 80% -c 25%
Quelle: (4)
Qualitätssichernde Maßnahmen
Um die syntaktische Korrektheit der Konfiguration zu prüfen, geben wir folgenden Befehl ein:
icinga -v /etc/icinga/icinga.cfg
[stextbox id=”info”]Tipp: In größeren Umgebungen kann es von Vorteil sein, die einzelnen Netzwerkkomponenten mit einem eindeutigem DNS-Hostnamen eingetragen.[/stextbox]
Anhang A
Literaturverzeichnis
(1) [nagios-buch] Wolfgang Barth, Nagios System- und Netzwerk-Monitoring, Open Source Press, 2008
(2) [icinga-webseite] Icinga, http://www.icinga.org
(3) [pnp-webseite] PNP, http://docs.pnp4nagios.org
(4) [nagios-doku] Nagios3, http://nagios.sourceforge.net/docs/3_0/
Anhang B
Glossar
CGI-Programme/Skripte – Das Common Gateway Interface (zu deutsch etwa „Allgemeine Vermittlungsrechner-Schnittstelle“) kann Webseiten dynamisch generieren. In Nagios werden die Statusberichte in der Weboberfläche mittels CGI-Programmen erstellt.
DNS – Der Domain Name Service ist ein Dienst zur Auflösung von Hostnamen in IP-Adressen und umgekehrt.
PING – Dies ist ein Programm, mit dem überprüft werden kann, ob ein bestimmter Host erreichbar ist und welche Zeit das Routing zu diesem hin und wieder zurück in Anspruch nimmt.
SMTP – Das Simple Mail Transfer Protocol (zu deutsch etwa „Einfaches E-Mail-Sendeverfahren“) ist ein Protokoll der Internetprotokollfamilie, das zum Austausch von E-Mails in Computernetzen dient.
SNMP – Das Simple Network Management Protocol (zu deutsch etwa „einfaches Netzwerkverwaltungsprotokoll“) dient zur Verwaltung von Netzwerkgeräten. Alle Parameter die über das Netzwerk ausgelesen und gesetzt werden können sind in der Management Information Base von dem jeweiligen Gerät eingetragen.
Anhang C
Abhängigkeitsprüfungen
Das nachfolgende Bild zeigt ein Diagramm von Netzwerkkomponenten und deren Abhängigkeiten, die von Nagios überwacht werden.
Switch2 ist in diesem Beispiel gerade nicht mehr erreichbar und somit in einen Problemzustand gewechselt. Nagios muss feststellen, ob der Host selber down ist oder nur nicht mehr erreichbar ist, weil eine weitere Netzwerkkomponente zuvor ausgefallen ist.
Es werden parallele Prüfungen für die direkten Nachbarn ausgelöst. Monitor1 und File1 werden zudem gleichzeitig parallel überprüft, da Switch2 von diesen abhängig ist.
Quelle: (4)
Anhang D
Topologie eines Beispielnetzwerks
Quelle: (1)
1.) ein kritischen Zustand eines Dienstes wird festgestellt
2.) der dazu passende Host wird überprüft und ist nicht erreichbar
3.) die Abhängigkeiten des Hosts werden parallel überprüft
4.) der switch1 ist noch vom Nagios-Server (nagios) aus zu erreichen
5. – 6.) die nachfolgenden Netzwerkkomponente sind momentan nicht erreichbar
In diesem Beispiel würde nur eine Benachrichtigung für den ausgefallenen switch2 generiert werden.
