Server- und Client-Überwachung mit Zabbix, Teil 2: Frontend

18.07.2005 von Jürgen Donauer
Die Server-Überwachung mit Zabbix per Kommandozeile ist nicht jedermanns Sache. Mit dem Frontend von Zabbix erhalten Sie zusätzlich Reports und können so einfach Trend-Analysen vornehmen.

Im ersten Teil des Workshops haben wir beschrieben, wie Sie Zabbix auf Client und Server einrichten und Überwachungs-Agenten erstellen. Ab jetzt verlassen Sie die Kommandozeile vorerst. Rufen Sie das Frontend im Browser mit

http://<zabbix-server>/zabbix/

auf und loggen Sie sich als admin ohne Passwort ein.

Die oberste Reihe mit Schaltflächen liefert nur gesammelte Informationen, die der Zabbix-Server zur Verfügung stellt. Sie ist auch von allen Benutzern erreichbar, die ein Login zu dem Frontend haben. Über die mittlere Reihe lassen sich der Zabbix-Status und ein Verfügbarkeitsreport abrufen. Über die untere Menüleiste stellen Sie sämtliche Konfigurationen ein.

Als Erstes sollten Sie den Account admin mit einem Passwort ausstatten. Dies erfolgt im Unterordner USERS. Neben dem admin-Benutzer finden Sie einen Change-Button. Hier können Sie das Passwort des Administrators ändern. Weiterhin erlaubt diese Maske das Einrichten von neuen Benutzern und Gruppen mit verschiedenen Rechten. Diese haben dann je nach Rechtevergabe Zugriff auf bestimmte Ressourcen von Zabbix.

Beide Teile dieses Artikels und eine Vielzahl weiterer Artikel rund um das Thema Linux-Server finden Sie in unsererm aktuellen Compact Linux-Komplettpaket. Zusätzlich enthält das Compact eine DVD mit CentOS in der 32- und 64-Bit-Version.

CONFIG-Maske

In der CONFIG-Maske richten Sie ein, wie lange Zabbix Alarminformationen speichern soll. Weiterhin geben Sie hier an, in welcher Form das Monitoring-Tool Sie im Falle eines Alerts unterrichtet. Soll dies per E-Mail geschehen, so tragen Sie hier einen SMTP-Server und die Absenderadresse ein. Ein sprechender Name, nach dem sich in einem E-Mail-Client gut filtern lässt, ist hier zu empfehlen. Schließlich soll die Alarm-Mail sofort erkennbar sein und nicht untergehen.

Clients hinzufügen

Unter HOSTS fügen Sie nun einen Client hinzu, auf dem der Zabbix-Agent schon laufen sollte. Tragen Sie hierzu einen Namen für den zu überwachenden Rechner ein. Sie haben die Möglichkeit, einen Rechner anhand von dessen IP-Adresse anzusprechen, wenn Sie diesen unter einem anderen Namen anlegen möchten, als er im Netzwerk bekannt ist. Setzen Sie hierzu den entsprechenden Haken und tragen die IP-Adresse des Clients ein. Wenn Sie viele Clients im Netzwerk haben, bietet diese Maske auch die Möglichkeit, verschiedene Gruppen einzurichten. So behält man später besser den Überblick.

Der Eintrag beim Listenport muss dem in der zabbix_agentd.conf angegebenen entsprechen. Beim Status lassen sich Monitored, Not Monitored und Template eintragen. Wählen Sie hier Template, so können Sie diese Konfiguration speichern und später für andere Clients wieder auswählen. In der letzten Zeile besteht die Möglichkeit, dem zu überwachenden Rechner ein vorgefertigtes Template mitzugeben. Das erleichtert die anschließende Einrichtung der ITEMS sehr.

Einrichtung der zu überwachenden Services (ITEMS)

Nachdem im vorausgegangenen Schritt das Template für einen Unix-Host ausgewählt wurde, ist die Liste für Rechner tux-juergen in der ITEMS-Maske schon prall gefüllt. Sie können hier nun durch Klicken bestimmen, welche Dienste Sie überwachen möchten und welche nicht. Um Ressourcen zu schonen, überwacht man nur, was auch auf dem Server läuft. Mit dem Button Change lassen sich bestimmte Einstellungen verändern.

Dies ist zum Beispiel bei der Überwachung des Webservers vom SLES 9 notwendig. Sieht man sich beim Item „Number of running processes apache“ den Key genauer an, so enthält dieser den Eintrag proc_cnt[httpd]. Das heißt, Zabbix sucht auf dem Client alle Prozesse, die httpd heißen, und zählt diese. Auf dem SLES 9 gibt es aber keinen solchen Prozess, selbst wenn Apache gestartet ist. Mit einem

ps -aef | grep http

auf dem SUSE-Rechner stellt man fest, dass der Webserver-Prozess

httpd2-prefork

heißt. Somit muss man diesen Key entsprechend ändern. Die Zeile sieht dann folgendermaßen aus:

Key proc_cnt[httpd2-prefork]

Konfigurieren der Trigger

Ein Trigger macht nichts anderes, als beim Eintreten einer bestimmten Situation eine Aktion durchzuführen. Springt beispielsweise die Anzahl der Webserver-Prozesse auf null, bedeutet dies, dass kein einziger Apache-Prozess mehr läuft. Der Webserver ist also „down“.

Zabbix reagiert auf diesen Fall und stößt den vorher konfigurierten Trigger an, der jetzt eine E-Mail abschickt. Steigt die Anzahl der Webserver-Prozesse wieder auf einen Wert größer als null, können Sie den Trigger so konfigurieren, dass er wiederum eine E-Mail mit einer „alles wieder ok“-Meldung schickt. Beim Status lässt sich wieder einstellen, ob der jeweilige Trigger aktiv oder inaktiv ist.

Mit dem Change-Button können Sie, falls notwendig, den Schweregrad (Severity) oder sogar die Expression ändern. Was diese Expression genau aussagt, können Sie in der Dokumentation nachlesen. Aber nur in den seltensten Fällen müssen Sie an diesen Ausdrücken schrauben.

Mit dem Action-Knopf richten Sie nun den eigentlichen Trigger ein. Hier definieren Sie als Erstes, an wen die Meldung gehen soll. Das kann eine Gruppe oder ein Einzelanwender sein. Im nächsten Feld spezifizieren Sie die Gruppe oder den Benutzer. Das dritte Feld gibt an, bei welchem Zustand oder Zustandswechsel des Triggers die Aktion ausgelöst werden soll. Den Eintrag bei Subject finden Sie später genau so in der Betreffzeile der gesendeten E-Mail wieder. Nur der Ausdruck {HOSTNAME} wird in den entsprechenden Rechnernamen umgewandelt. Beim Message-Body können Sie Ihrer Fantasie freien Lauf lassen.

Es bietet sich jedoch an, einen kurzen, aber prägnanten Text zu verwenden. Alles was nach „Latest data“ steht, gibt in der Nachricht dann genauere Auskunft über die letzten ermittelten Daten. Zabbix füllt den unteren Abschnitt sogar selbstständig aus. Es schadet auf keinen Fall, diese Informationen beizubehalten.

Im letzten Punkt können Sie nun bestimmen, ob die Konfiguration nur für diesen Trigger, für alle Trigger dieses Hosts oder global für alle Trigger gelten soll. Letzteres ist allerdings nur sinnvoll für allgemeine Nachrichten. Es macht wenig Sinn, wenn eine Apache-Fehlermeldung beim Ausfall des FTP-Servers erscheint.

NETWORK MAPS, GRAPHS, SCREENS

Diese Funktionen bedürfen eigentlich keiner großen Erklärung. Hiermit lässt sich der Status einer Server-Client-Landschaft visualisieren. Dieses Feature können Sie nutzen, um bei einzelnen Servern/Clients Prozesse in Diagrammen darzustellen. Graphen erleichtern Analysen oft.

Ein praktisches Beispiel wäre die Überwachung des täglichen oder wöchentlichen Datenzuwachses, um abschätzen zu können, wann voraussichtlich der Plattenplatz zu Ende geht. Durch ein bisschen Probieren kommt man schnell dahinter, wie sich diese Funktionen konfigurieren und optimal einsetzen lassen. Ein Blick in die Dokumentation hilft auch hier weiter. Die SCREEN-Funktion lässt sich zum Beispiel so einrichten, dass Sie ständig einen Überblick haben, wie stark Ihre Prozessoren ausgelastet sind. Ob dies nun die CPU-Last gesamt oder einzelne Prozessoren betrifft, konfigurieren Sie ganz nach Gusto.

Die obere Schalterleiste

Die obere Leiste dient der reinen Information. Diese ist auch von Nicht-Admins einsehbar und gibt den Zustand der zu überwachenden Systeme wieder. LATEST VALUES stellt die letzten empfangenen Daten über ein System bereit. Sie können übersichtlich ablesen, was auf dem jeweiligen System gerade passiert.

Mit den Schaltern Graph, Trend und Compare stellt das Monitoring-Tool weitere aussagekräftige Details in Form von übersichtlichen Grafiken dar.

Unter QUEUE finden Sie die wartenden, vom System abzuarbeitenden Ereignisse. Ist diese Warteschlange dauernd extrem lang, sollten Sie einschreiten und die Abfrage-Intervalle erhöhen. ALARMS gibt alle Ereignisse wieder, denen eine Statusänderung mit ON oder OFF zu Grunde liegt. ALERTS wiederum gibt nur diejenigen an, für die auch ein Trigger ausgelöst wurde.

Eigene Items erstellen

Wie bereits erwähnt, gibt Ihnen Zabbix die Möglichkeit, eigene Items zu erstellen. Dies ist manchmal nötig, wenn Sie etwas überwachen möchten, das in Zabbix nicht implementiert ist. So ein Fall ist zum Beispiel die Überwachung jeder einzelnen CPU. Eigene Items unterliegen nur zwei Einschränkungen. Erstens muss der Befehl auf der Kommandozeile ausführbar sein. Zweitens muss als Ergebnis dieses Befehls ein einzelner Wert herauskommen. Ansonsten dürfen Sie alles verwenden, was die Shell, die Zusatzprogramme und so weiter bieten. Das Item selbst geben Sie in der Datei

/etc/zabbix/zabbix_agentd.conf

an. Ein Beispiel verdeutlicht dies:

UserParameter=cpu0[last],/usr/bin/sar 1 1 -P 0|/bin/grep ^[Average]|/bin/grep [0-9]|/bin/awk '{a=100-$7} ; END {printf a}'

Den Schlüssel für das Item definieren Sie über UserParameter=cpu0[last]. Diesen verwenden Sie im Zabbix-Frontend, um das eigene Item zu adressieren.

Alles nach dem Komma repräsentiert im Prinzip einen Kommandozeilenbefehl, der einen einzelnen Wert zurückgibt. Achten Sie darauf, möglichst den kompletten Pfad der Programme anzugeben. Obiger Befehl in seine einzelnen Teile aufgeschlüsselt erfüllt folgende Aufgabe. Das Programm sar gibt detaillierte Informationen über die derzeitige Auslastung aller Prozessoren an.

/usr/bin/sar 1 1 -P 0

sagt aus, dass nur Informationen über den ersten Prozessor (CPU0) zurückgegeben werden. Welche Möglichkeiten Sie noch mit sar haben, finden Sie in den Manpages (man sar). Da sar mit diesen Schaltern immer noch zu viele Informationen für unsere Bedürfnisse ausgibt, filtern Sie mit grep die weitere Ausgabe. Mit

/bin/grep ^[Average]

entlocken Sie dem System alle Zeilen, die mit dem Wort Average anfangen. Somit gibt das System nur noch zwei Zeilen wieder, was aber immer noch viel zu viel ist. Mit dem nächsten Befehl

/bin/grep [0-9]

teilen Sie dem System mit, dass Sie nur solche Zeilen erhalten wollen, die Ziffern enthalten. Für das Beispiel ist jedoch nur Spalte sieben interessant, da diese den Idle-Wert von CPU0 beinhaltet. Das Beispiel sollte aber die Auslastung und nicht den Idle-Wert an Zabbix geben. Dafür dient das Programm awk. Sie ziehen einfach den Wert aus Spalte sieben von 100 ab und lassen sich das Ergebnis auf dem Bildschirm anzeigen.

/bin/awk '{a=100-$7} ; END {printf a}'

Jetzt liefert die Befehlszeile einen einzelnen Wert, den Zabbix verarbeiten kann. Um genau zu sehen, was der Befehl macht, geben Sie am besten den sar-Befehl in einer Kommandozeile ein. Anschließend hängen Sie Schritt für Schritt die mit grep und awk verwendeten Filter an.

Dokumentation

Die in Englisch gehaltene Zabbix-Dokumentation ist sehr ausführlich, übersichtlich und komplett. Sie sollten auf jeden Fall einen Blick in das 162 Seiten starke Dokument werfen, denn es handelt sich dabei nicht wie bei vielen anderen Open-Source-Programmen um zusammengestückelte Informationen, bei denen man das meiste durch „trial and error“ herausfinden muss. Zudem ist es leicht verständlich gehalten und bietet viele Beispiele.

Fazit

Bei Zabbix handelt es sich um ein Vorzeigeprogramm, an dem sich nicht nur viele Open-Source-Projekte ein Beispiel nehmen könnten, sondern auch eine Reihe von kommerziellen Produkten. Das Programm ist zwar komplex, aber einfach zu verstehen und unkompliziert zu bedienen.

Dem Administrator wird die Arbeit mit Zabbix extrem erleichtert, dennoch haben Sie alle Freiheiten. Es besteht die Möglichkeit, eigene auf die Netzwerklandschaft optimal zugeschnittene Items zu erstellen, auch plattformübergreifend.

Zabbix steht seinen kostenpflichtigen Konkurrenten in nichts nach. Die Dokumentation ist mehr als vorbildlich. Sollten Sie Ihre Server im Auge behalten wollen, ohne ständig daneben stehen zu müssen oder Ihre Anwender als Überwacher zu missbrauchen, legen wir Ihnen Zabbix wirklich ans Herz.