Systemüberwachung mit Zabbix - Teil 2

Elemente und Trigger

Eigene Trigger

Nachdem wir nun die Prinzipien der Software kennen gelernt haben, ist es an der Zeit, eigene Trigger zu definieren, um nicht gelistete Applikationen, Dienste oder Ereignisse zu überwachen. Trotz des recht großen Funktionsumfangs ist diese Aufgabe nicht sonderlich schwer.

Wie Sie vielleicht schon bei Ihrer Untersuchung gesehen haben, bietet Zabbix im Konfigurationsmenü neben der Möglichkeit, grafische Anzeigen zu erstellen, auch eine Option »Items« (»Elemente«) und »Trigger« (»Auslöser«) zu Wahl an. Beide Komponenten dienen dazu, neue Ereigniskontrollen zu erstellen. Die Vorgehensweise dazu ist relativ simpel.

Zum einen ist es notwendig, ein neues Element zu erstellen. Dieses dient als Kontrollbasis des Systems. So kann ein Element zum Beispiel die Zahl der laufenden Prozesse einer Applikation abfragen oder die belegten Ports untersuchen. Für sich alleine ist ein Element nur eine Abfrageeinheit ohne eine reaktive Komponente. Erst durch die Verknüpfung eines Elements mit einem Trigger erreicht der Anwender das gewünschte Resultat.

Beispielsweise könnte ein Element die Zahl der laufenden Prozesse des Dienstes »foo« abfragen. In einem Trigger wird nun die vom Element errechnete Zahl mit einer logischen Operation verknüpft. Fällt zum Beispiel die Zahl der Prozesse auf 0, bedeutet es, dass unser Dienst »foo« ausgefallen ist.

Trigger erstellen

Um Ihnen die Suche nach Diensten zu erleichtern, haben wir eine simple Applikation gestrickt. Keine Sorge, sie ist ungefährlich und dient nur der Demonstration der Triggerfunktionalität. Kopieren Sie bitte den nachfolgenden Quelltext in eine neue Datei unter dem Namen »udaemon.c«:

# vi udaemon.c
/* udaemon.c */
/* Make: gcc udaemon.c -o udaemon */
int main(){
 while (1)
 sleep(10);
}

Compilieren Sie bitte die Applikation mit dem Befehl:

# gcc udaemon.c -o udaemon

Selbstverständlich können Sie auch einen bei Ihnen verwendeten Dienst benutzen.

Mirko Lindner

Element erstellen

Mirko Lindner

Trigger erstellen

Um einen neuen Trigger anmelden zu können, bedarf es der vorherigen Erstellung eines Elements. Gehen Sie dazu in den Menüpunkt »Configuration->Items« (»Konfiguration->Elemente«) und wählen, falls noch nicht geschehen, aus der Liste der Systeme unser System »LOCALHOST« aus. Nun sollte die Seite alle Elemente für das System »LOCALHOST« anzeigen.

Um die Erstellung eines neuen Elements zu beschleunigen, wählen Sie bitte das Element »Number of running processes sshd« aus. In der nun erscheinenden Maske können Sie zwar nichts ändern, das stört uns aber nicht, das Element dient uns als Basis für ein neues Element. Kopieren Sie das Element mit dem Befehl »Clone« (»Kopieren«).

Nun sind Sie in der Lage, die Maske Ihren Bedürfnissen anzupassen. Ändern Sie die Beschreibung in »Number of running processes udaemon« und den Key in »proc.num[udaemon]«. Den Rest können wir belassen, wie er ist. Speichern Sie das neue Element mit »Save« (»Speichern«). Ihr neues Element wurde nun dem System »LOCALHOST« hinzugefügt.

Damit Zabbix Ihre Elemente nutzen kann, bedarf es nun der Erstellung eines neuen Triggers. Gehen Sie dazu in »Configuration->Triggers« (»Konfiguration->Auslöser«) und wählen auch hier aus der Liste der Systeme das von uns erstellte System »LOCALHOST« aus. Wie im Falle eines Elements werden wir uns auch hier eines bereits existierenden Triggers bedienen. Klicken Sie bitte »Sshd is not running on LOCALHOST«. In der neuen Maske duplizieren Sie das Element mit »Clone« (»Kopieren«). Nun ändern Sie den Namen des Triggers in »udaemon is not running on {HOSTNAME}« und die Bedingung in »{LOCALHOST:proc.num[udaemon].last(0)}<1«.

Die eigentliche Kontrolle des Triggers übernimmt die Bedingung. Die Syntax ist dabei nicht wirklich schwer zu verstehen. Während LOCALHOST den Namen des Systems bedeutet, definiert »proc.num[udaemon].last(0)« das aktuellen Wert des von uns erstellten Elements. Ist dieser kleiner als 1, ist die Bedingung wahr und Zabbix meldet »True«, was im Klartext den Ausfall des Dienstes bedeutet.

Eigene Trigger testen

Nun ist es an der Zeit, den neuen Trigger zu testen. Durch die Erstellung des neuen Triggers wurde dieser auch in das System eingebunden. Da wir unsere Testapplikation nur compiliert und nicht gestartet haben (Sie erinnern sich an »udaemon«), meldet Zabbix bei der Betrachtung von »Monitoring->Screens« (»Überwachung->Übersichtstafeln«) den Fehler »udaemon is not running on LOCALHOST«. Starten Sie jetzt die Applikation mit:

# ./udaemon

Die Anzeige der Übersichtstafel müsste sich nun bald ändern. Der »Fehler« ist nach einer gewissen Zeit verschwunden. Wir haben unseren ersten selbsterstellten Trigger erfolgreich getestet.

Abschließendes

Unsere Anleitung zeigt nur einen Bruchteil der Möglichkeiten von Zabbix. Alle Funktionen detailliert zu beschreiben, würde den Rahmen des Artikels sprengen. Vor allem die Trigger-Funktionalität erweist sich bei der täglichen Arbeit als sehr ergiebig und flexibel. Hinzu kommt noch, dass Zabbix auch auf externe Skripte zugreifen kann. So ist es für geübte Administratoren ein Leichtes, auch komplexe Abfragen in Form eines Skripts zu erstellen und die Ausgaben überwachen lassen. Auch die Kontrolle von HTML-Seiten ist möglich.

Durch die Trennung des Servers kann das System sowohl im Heimbereich als auch in großen Umgebungen genutzt werden. Dazu können Systeme in Gruppen zusammengefasst werden und Trigger nicht nur einem einzigen Host, sondern auch einer kompletten Gruppe zugewiesen werden.

Mit der kommenden Version soll Zabbix über bessere Datenbank-Überwachungs-Funktionen und über eine flexible SNMP-Überwachung verfügen. Die Überprüfung von verteilten Systemen soll darüber hinaus erweitert werden. Ferner soll Zabbix in der Version 1.6 auch IPv6 unterstützen.