Mit Hilfe selbst geschriebener Plugins spannt der clevere Perl-Programmierer das Netzwerk-Monitoring-Tool Nagios für vielfältige Überwachungsaufgaben ein.

Plugin einbinden

Um das neue Plugin in eine existierende Nagios-Installation einzuhängen, kopiert der Admin das Skript »check_iostat« ausführbar ins Verzeichnis »/usr/local/nagios/libexec«. Die Nagios-Konfiguration erweitert er gemäß Abbildung 4 um ein Template namens »ez-service«, das später auch die Definition weiterer Plugins vereinfacht. Es ist gängige Praxis in Nagios-Konfigurationen, unter anderem Service-Templates zu definieren, die am Eintrag »register 0« erkennbar sind. Später erweitern Service-Definitionen diese Templates um spezielle Einträge.

Die Konfiguration »define service« legt in Abbildung 4 den neuen Iostat-Service an. Er bindet das vorher definierte Template mit »use ez-service« ein und übernimmt damit zahlreiche Parameter für Testabläufe, E-Mail-Benachrichtigungen und vieles mehr. Der Eintrag »notification_interval 0« verhindert zum Beispiel, dass Nagios für ein Problem mehrere Mails verschickt.

Mit »normal_check_interval« bestimmt der Admin den Zeitabstand zwischen den Service-Tests in Minuten und »max_check_attempts« legt fest, nach wie vielen fehlgeschlagenen Tests Nagios eine Benachrichtigung schickt. Die »service_notification_options« konfigurieren, bei welchen Zustandsänderungen Nagios sich meldet: Die Option »w« bedeutet Warning, »u« steht für Unknown, »c« für Critical, »r« für Recovery. Ähnliches gilt für »host_notification_options«, hier bedeutet zusätzlich »d« Down.

Wenn der Nagios-Server wegen eines Netzwerkproblems selbst von der Umwelt abgeschnitten ist, kommt natürlich auch keine Warnung per E-Mail übers Internet an. In diesem Fall erreicht den erleichterten Admin aber zumindest die Recovery-Mail, sobald das Problem behoben ist.

Abbildung 3: Das Kommando »iostat 1 2« gibt im zweiten Teil die aktuelle CPU- und Platten-Auslastung eines Servers aus.

Automatisch reagieren

Ein weiteres sehr nützliches Feature sind Event-Handler, die Aktionen definieren, die Nagios selbstständig ausführt, wenn es bestimmte Probleme erkennt. Manche Schwierigkeiten kann das System auf diese Weise aus dem Weg räumen, bevor es die Hilfe eines Admin braucht.

Ein Service ist in Nagios immer einem Host zugeordnet, den das System separat auf Verfügbarkeit testet. Die Host-Spezifikation verlangt weitere Einträge in der Konfigurationsdatei. Der Eintrag »host_name dreamhost« gibt an, dass ein solcher Host konfiguriert ist.

Der Parameter »check_command« der Service-Definition spezifiziert den Aufruf des Plugin »check_iostat«. Es wird jedoch nicht direkt aus der Service-Definition heraus aufgerufen, sondern über ein weiter oben mit »define command« konfiguriertes Kommando, das die auszuführende Kommandozeile festlegt. Die dabei übergebene URL ersetzt den Platzhalter ». Diese URL übergab der Eintrag »check_command« in der Service-Definition dem »iostat«-Kommando getrennt durch ein Ausrufezeichen.

Auch die Angabe »24x7« für die Parameter »check_period« und »notification_period« erfordert weitere Einträge, die die E-Mail des Admin und seine Verfügbarkeit definieren. Unter [1] ist dafür die Beispieldatei »eznagios.cfg« erhältlich, die sich mit »cfg_file=/usr/local/nagios/etc/eznagios.cfg« in die zentrale Konfigurationsdatei »nagios.cfg« einbinden lässt. Außerdem definiert sie weitere Nagios-Tests, die anzeigen, wie voll die Festplattenpartitionen sind oder ob der Router oder der DNS-Server des Providers noch funktionieren.

Abbildung 4: Die Nagios-Konfiguration für das neue Iostat-Plugin verwendet ein Template.

Mit Hilfe selbst geschriebener Plugins spannt der clevere Perl-Programmierer das Netzwerk-Monitoring-Tool Nagios für vielfältige Überwachungsaufgaben ein.