12.4. Überwachung

Monitoring ist ein allgemeiner Ausdruck, und die verschiedenen damit verbundenen Aktivitäten haben mehrere Ziele: einerseits ist es durch die Verfolgung der Ressourcennutzung eines Rechners möglich, seine volle Auslastung und die daraufhin erforderlichen Nachrüstungen vorherzusehen; andererseits kann ein auftretendes Problem frühzeitiger behoben werden, wenn der Administrator informiert wird, sobald ein Dienst nicht verfügbar ist oder nicht richtig funktioniert.

Munin deckt den ersten Bereich ab, indem es Diagramme der vergangenen Werte einer Reihe von Parametern anzeigt (verwendetes RAM, belegter Plattenplatz, Prozessorlast, Netzwerkverkehr, Apache/MySQL-Auslastung und so weiter). Nagios umfasst den zweiten Bereich, indem es regelmäßig überprüft, ob die Dienste funktionieren und verfügbar sind, und indem es über geeignete Kanäle (E-Mails, Textnachrichten und so weiter) Warnungen verschickt. Beide haben eine modulare Bauweise, wodurch es einfach ist, neue Plugins zur Überwachung bestimmter Parameter oder Dienste zu erstellen.

ALTERNATIVE Zabbix, ein integriertes Monitoringprogramm

Obwohl Munin und Nagios sehr weit verbreitet sind, sind sie nicht die einzigen Akteure auf dem Gebiet des Monitoring, und jedes von ihnen erledigt nur eine Hälfte der Aufgabe (grafische Darstellungen auf der einen Seite und Warnungen auf der anderen). Zabbix integriert dagegen beide Teile des Monitorings; es hat außerdem eine Web-Schnittstelle zur Konfigurierung der häufigsten Aspekte. Es hat sich in den vergangenen Jahren rasant weiterentwickelt und muss inzwischen leider als ernst zu nehmender Herausforderer angesehen werden. Den Monitoring-Server installiert man mittels zabbix-server-pgsql (oder zabbix-server-mysql), gegebendenfalls zusammen mit zabbix-frontend-php um ein Web-Interface bereitzustellen. Auf dem zu überwachenden Rechner (Host) installiert man den zabbix-agent, der die Daten an den Monitororing-Server liefert.

→ http://www.zabbix.com/

12.4.1. Munin einrichten

Munin hat die Aufgabe, zahlreiche Rechner zu überwachen; daher verwendet es natürlich eine Client/Server-Architektur. Der zentrale Host - der Grapher - sammelt Daten aller überwachten Hosts und erzeugt Verlaufsdiagramme.

12.4.1.1. Zu überwachende Hosts konfigurieren

Der erste Schritt besteht darin, das Paket munin-node zu installieren. Der Daemon, der mit diesem Paket installiert wird, nimmt an Port 4949 Verbindungen an und sendet die Daten zurück, die von allen aktiven Plugins gesammelt werden. Jedes Plugin ist ein einfaches Programm, das sowohl eine Beschreibung der gesammelten Daten als auch die jüngsten Messwerte wiedergibt. Plugins werden in /usr/share/munin/plugins/ gespeichert, aber nur diejenigen mit einer symbolischen Verknüpfung in /etc/munin/plugins/ werden tatsächlich benutzt.

Wenn das Paket installiert ist, wird in Abhängigkeit von der verfügbaren Software und der aktuellen Konfiguration des Hosts ein Satz aktiver Plugins festgelegt. Diese Autokonfiguration hängt jedoch von einer Funktion ab, die jedes Plugin bereitstellen muss, und es empfiehlt sich normalerweise, die Ergebnisse zu überprüfen und von Hand nachzustellen. Das Duchsehen von Plugin Gallery kann interessant sein, auch wenn nicht alle Plugins eine ausführliche Dokumentation aufweisen. Alle Plugins sind jedoch Skripte, und die meisten von ihnen sind recht einfach aufgebaut und ausführlich kommentiert. Das Durchsuchen von /etc/munin/plugins/ ist daher eine gute Methode, um eine Vorstellung davon zu bekommen, worum es bei jedem Plugin geht, und welche entfernt werden sollten. Ebenso lässt sich ein interessantes Plugin, das man in /usr/share/munin/plugins/ gefunden hat, einfach durch die Erstellung einer symbolischen Verknüpfung mit dem Befehl ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/ aktivieren. Beachten Sie, dass ein Plugin, dessen Name mit einem Unterstrich "_" endet, einen Parameter erwartet. Dieser Parameter muss im Namen des symbolischen Linksangegeben werden; beispielsweise muss das "if_" plugin mit einem symbolischen Link if_eth0 aktiviert werden, damit es den Netzwerkverkehr auf der Schnittstelle eth0 überwacht.

Nachdem alle Plugins richtig eingerichtet sind, muss die Konfiguration des Daemons aktualisiert werden, um die Zugriffskontrolle für die gesammelten Daten zu beschreiben. Hierzu sind allow-Anweisungen in der Datei /etc/munin/munin-node.conf erforderlich. Die Standardkonfiguration lautet allow ^127\.0\.0\.1$ und ermöglicht nur Zugriff auf den lokalen Host. Ein Administrator fügt gewöhnlich eine ähnliche Zeile mit der IP-Adresse des Grapher-Hosts hinzu und startet den Daemon anschließend mit service munin-node restart neu.

WEITERE SCHRITTE Lokale Plugins erstellen

Munin enthält eine ausführliche Anleitung darüber, wie sich Plugins verhalten sollten und wie man neue Plugins entwickelt.

→ http://munin-monitoring.org/wiki/plugins

Ein Plugin wird am besten getestet, indem man es unter den gleichen Bedingungen laufen lässt, unter denen es laufen würde, wenn es durch munin-node in Gang gesetzt würde; dies kann dadurch simuliert werden, dass man munin-run plugin als Root ausführt. Ein möglicher weiterer Parameter, der diesem Befehl hinzugefügt wird (wie zum Beispiel config), wird als Parameter an das Plugin weitergeleitet.

Wenn ein Plugin mit dem Parameter config aufgerufen wird, muss es sich selbst beschreiben, indem es einen Satz von Feldern wiedergibt:

$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average

Die verschiedenen möglichen Felder sind in der Spezifikation „Plugin Reference“ auf der Munin-Webseite beschrieben.

→ http://munin.readthedocs.org/en/latest/reference/plugin.html

Wenn es ohne einen Parameter aufgerufen wird, gibt das Plugin einfach die zuletzt gemessenen Werte wieder; so könnte zum Beispiel die Ausführung des Befehls sudo munin-run load die Meldung load.value 0.12 ergeben.

Wenn schließlich ein Plugin mit dem Parameter autoconf aufgerufen wird, sollte es mit „yes“ (und dem Beendigungsstatus 0) oder mit „no“ (und dem Beendigungsstatus 1) antworten, je nachdem, ob das Plugin auf diesem Host aktiviert sein sollte oder nicht.

12.4.1.2. Den Grapher konfigurieren

Der „Grapher“ ist einfach der Rechner, der die Daten aggregiert und die entsprechenden Diagramme erzeugt. Die erforderliche Software befindet sich in dem Paket munin. Die Standardkonfiguration führt den Befehl munin-cron (alle 5 Minuten) aus, der die Daten von allen Hosts, die in /etc/munin/munin.conf aufgelistet sind (nur der lokale Host ist hier standardmäßig aufgeführt), sammelt, die vergangenen Daten in RRD-Dateien (Round Robin Database, einem Dateiformat zur Speicherung von Daten, die sich im Verlaufe der Zeit ändern) unter /var/lib/munin/ speichert und in /var/cache/munin/www/ eine HTML-Seite mit den Diagrammen erstellt.

Alle überwachten Rechner müssen daher in der Konfigurationsdatei /etc/munin/munin.conf aufgeführt sein. Jeder Rechner ist als vollständiger Absatz aufgelistet mit einer Bezeichnung, die dem Rechner entspricht und wenigstens einem address-Eintrag, der die dazugehörige IP-Adresse angibt.

[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes

Die Absätze können komplexer sein und zusätzliche Diagramme beschreiben, die durch die Kombination von Daten mehrerer Rechner erzeugt werden könnten. Die in der Konfigurationsdatei bereitgestellten Beispiele sind ein guter Ausgangspunkt für die Anpassung.

Der letzte Schritt besteht darin, die erstellten Seiten zu veröffentlichen; hierzu muss ein Webserver konfiguriert werden, so dass der Inhalt von /var/cache/munin/www/ auf einer Webseite zur Verfügung gestellt wird. Der Zugriff auf diese Webseite ist häufig beschränkt, indem entweder ein Authentifizierungsmechanismus oder eine IP-basierte Zugriffskontrolle eingesetzt wird. Siehe Abschnitt 11.2, „Webserver (HTTP)“ für entsprechende Einzelheiten.

12.4.2. Nagios einrichten

Im Gegensatz zu Munin ist es bei Nagios nicht unbedingt erforderlich, auf den überwachten Hosts irgendetwas zu installieren; in den meisten Fällen wird Nagios dazu verwendet, die Verfügbarkeit von Netzwerkdiensten zu überprüfen. Nagios kann sich zum Beispiel mit einem Webserver verbinden und nachprüfen, ob eine bestimmte Webseite in einer bestimmten Zeit erhältlich ist.

12.4.2.1. Installieren

Der erste Schritt zur Einrichtung von Nagios besteht darin, die Pakete nagios3, nagios-plugins und nagios3-doc zu installieren. Mit der Installation dieser Pakete wird die Webschnittstelle konfiguriert und ein erster nagiosadmin-Benutzer eingerichtet (für den nach einem Passwort gefragt wird). Weitere Benutzer werden einfach hinzugefügt, indem sie mit dem Apache-Befehl htpasswd in die Datei /etc/nagios3/htpasswd.users eingetragen werden. Falls während der Installation keine Debconf-Fragen angezeigt wurden, kann der Befehl dpkg-reconfigure nagios3-cgi dazu eingesetzt werden, das nagiosadmin-Passwort festzulegen.

Mit der Eingabe von http://server/nagios3/ in einen Browser wird die Webschnittstelle angezeigt; man beachte insbesondere, dass Nagios auf dem Rechner, auf dem es läuft, bereits einige Parameter überwacht. Einige interaktive Funktionen, wie zum Beispiel das Hinzufügen von Kommentaren zu einem Host, laufen jedoch noch nicht. Diese Funktionen sind in der Standardkonfiguration für Nagios, die aus Sicherheitsgründen sehr restriktiv ist, deaktiviert.

Wie in /usr/share/doc/nagios3/README.Debian dargelegt, ist es zur Aktivierung einiger Funktionen erforderlich, /etc/nagios3/nagios.cfg zu editieren und ihren Parameter check_external_commands auf „1“ zu setzen. Wir müssen außerdem mit Befehlen wie den folgenden Schreibberechtigungen für das Verzeichnis einrichten, das Nagios benutzt:

# service nagios3 stop
[...]
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
# service nagios3 start
[...]

12.4.2.2. Konfigurieren

Die Webschnittstelle von Nagios ist recht schön, aber sie ermöglicht weder eine Konfigurierung noch kann sie dazu verwendet werden, überwachte Hosts und Dienste hinzuzufügen. Die gesamte Konfiguration wird über Dateien verwaltet, auf die in der zentralen Konfigurationsdatei /etc/nagios3/nagios.cfg verwiesen wird.

Man sollte in diese Dateien ohne ein Verständnis der Konzepte von Nagios nicht eindringen. Die Konfiguration führt Objekte der folgenden Art auf:

ein host ist ein zu überwachender Rechner;
eine hostgroup ist ein Satz von Rechnern, der in der Darstellung oder zur Berücksichtigung einiger gemeinsamer Konfigurationselemente zusammengefasst werden sollte;
ein service ist ein überprüfbares Element in Bezug auf einen Host oder eine Gruppe von Hosts. In den meisten Fällen wird es sich um die Überprüfung eines Netzwerkdienstes handeln, es kann aber auch bedeuten, dass überprüft wird, ob einige Parameter innerhalb eines zulässigen Bereichs liegen (zum Beispiel der freie Plattenplatz oder die Prozessorlast);
eine servicegroup ist ein Satz von Diensten, die zur Darstellung zusammengefasst werden sollen;
ein contact ist eine Person, die Warnmeldungen empfangen darf;
eine contactgroup ist ein Satz solcher Personen;
eine timeperiod ist ein Zeitraum, innerhalb dessen einige Dienste überprüft werden müssen;
ein command ist die Befehlszeile, die zur Überprüfung eines bestimmten Dienstes aufgerufen wird.

Je nach seiner Art hat jedes Objekt eine Anzahl von Eigenschaften, die angepasst werden können. Eine vollständige Liste wäre zu lang, um sie hier aufzuführen, jedoch sind die wichtigsten Eigenschaften die Beziehungen zwischen den Objekten.

Ein service verwendet einen command, um den Zustand einer Funktion auf einem host (oder einer hostgroup) innerhalb einer timeperiod zu überprüfen. Falls ein Problem vorliegt, verschickt Nagios ein Warnmeldung an alle Mitglieder der contactgroup, die mit diesem Dienst in Zusammenhang steht. Jedes Mitglied erhält die Meldung in Abhängigkeit von dem Kanal, der in dem entsprechenden contact-Objekt beschrieben ist.

Ein Vererbungssystem erleichtert es, einen Satz von Eigenschaften bei vielen Objekten gemeinsam zu benutzen, ohne Informationen zu duplizieren. Außerdem enthält die anfängliche Konfiguration eine Anzahl von Standardobjekten; so können in vielen Fällen neue Hosts, Dienste und Kontakte einfach dadurch festgelegt werden, dass sie von den bereitgestellten allgemeinen Objekten abgeleitet werden. Die Dateien in /etc/nagios3/conf.d/ sind eine gute Quelle für Informationen darüber, wie sie funktionieren.

Die Falcot Corp. Administratoren verwenden folgende Konfiguration:

Beispiel 12.3. /etc/nagios3/conf.d/falcot.cfg file

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.6
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Services to check on www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Services to check on ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}

Diese Konfigurationsdatei beschreibt zwei überwachte Hosts. Der erste ist der Webserver, und die Überprüfungen werden an den Ports für HTTP (80) und sicheres HTTP (443) durchgeführt. Nagios überprüft außerdem, ob ein SMTP-Server an Port 25 läuft. Der zweite ist der FTP-Server, und mit der Überprüfung wird unter anderem sichergestellt, dass eine Antwort innerhalb von 20 Sekunden gegeben wird. Bei einer längeren Verzögerung wird eine Warnung ausgegeben, bei mehr als 30 Sekunden gilt sie als kritisch. Die Webschnittstelle von Nagios zeigt auch an, dass der SSH-Service überwacht wird: dies geschieht wegen der Hosts, die zur Hostgruppe ssh-servers gehören. Der dazugehörige Standarddienst ist in /etc/nagios3/conf.d/services_nagios2.cfg festgelegt.

Man beachte die Verwendung der Vererbung: ein Objekt wird mit „use eltern-name“ dazu gebracht, von einem anderen Objekt zu erben. Das Elternobjekt muss identifizierbar sein, daher ist es erforderlich, ihm mit „name kennung“ eine Kennung zu geben. Falls das Elternobjekt kein wirkliches Objekt sein, sondern lediglich als Elter dienen soll, wird Nagios mitgeteilt, es nicht zu berücksichtigen, indem ihm die Eigenschaft „register 0“ zugeteilt wird, so dass Nagios das Fehlen einiger Parameter ignoriert, die anderenfalls erforderlich wären.

DOKUMENTATION Liste der Objekteigenschaften

Ein vertieftes Verständnis der verschiedenen Weisen, auf die Nagios konfiguriert werden kann, kann aus der Dokumentation gewonnen werden, die mit dem Paket nagios3-doc bereitgestellt wird. Diese Dokumentation ist direkt von der Webschnittstelle aus über den Link „Documentation“ in der oberen linken Ecke erreichbar. Sie enthält eine Liste aller Objekttypen mit allen Eigenschaften, über die sie verfügen. Sie erklärt auch, wie neue Plugins erstellt werden.

WEITERE SCHRITTE Ferntests mit NRPE

Mit vielen Nagios-Plugins ist es möglich, bestimmte Parameter zu überprüfen, die lokal auf einem Host verfügbar sind; wenn diese Überprüfungen für zahlreiche Rechner erforderlich sind, wobei eine zentrale Einrichtung die Daten sammelt, muss das Plugin NRPE (Nagios Remote Plugin Executor) eingesetzt werden. Hierzu muss das Paket nagios-nrpe-plugin auf dem Nagios-Server und das Paket nagios-nrpe-server auf den Hosts, auf denen die lokalen Tests laufen sollen, installiert werden. Letzteres erhält seine Konfiguration von /etc/nagios/nrpe.cfg. Diese Datei sollte die Tests auflisten, die aus der Ferne gestartet werden können, und die IP-Adressen der Rechner, die sie auslösen dürfen. Auf der Nagios-Seite werden diese Ferntests einfach dadurch aktiviert, dass mit dem neuen Befehl check_nrpe passende Dienste hinzugefügt werden.