Der große Schwall Benachrichtigungen reißt den Admin aus seinem wohlverdienten Tiefschlaf und er denkt sofort an den digitalen Untergang im Rechenzentrum. Voller Adrenalin schaut er auf sein Handy und stellt fest: Da war das Monitoring gründlich – zu gründlich um genau zu sein. Der Teufel steckt nun mal im Detail und die gewissenhafte Überwachung eines Servers ist die Ursache für den nächtlichen Adrenalinschub. Dabei wäre es vermeidbar gewesen – und mit nur wenigen Konfigurationszeilen mehr wären Nerven und der Geldbeutel (für den SMS-Versand) geschont geblieben. Das Zauberwort lautet „Serviceabhängigkeiten„.
Infrastrukturen werden komplexer, gesetzliche Anforderungen immer schärfer. So wird nicht nur der Webserver auf seine Erreichbarkeit überwacht, sondern auch einzelne Seiten – Startseite, Impressum, Shop-Produkte sind in der permanenten Überwachung. Während die Rechtsabteilung nur am Jahresende interessiert, ob das Impressum durchgehend verfügbar war, will der Vertrieb wissen, wie hoch die Offlinezeit des wichtigsten Produkt war. Den Admin interessiert in der Regel nur: Läuft der Webserver? Ist die Datenbank in Ordnung? Auch wenn er dazu angehalten ist, Shop und Impressum durchgehend online zu halten. Aus diesem Überwachungswahn entstehen schnell ganz viele Checks, die regelmäßig ausgeführt werden. So liest sich die Webserverkonfiguration dann auch mal wie folgt:
define service{
use full-service
host_name WEBSERVER
service_description HTTP
check_command check_http
}
define service{
use full-service
host_name WEBSERVER
service_description HTTP-IMPRESSUM
check_command check_http!-H company.example.com!-u /impressum.html !-e "Kontakt"
}
define service{
use full-service
host_name WEBSERVER
service_description HTTP-SHOP
check_command check_http!-H company.example.com!-u /produkt.php?id=123!-e "Staubsauger Premium 3000"
}
define service{
use full-service
host_name WEBSERVER
service_description MYSQL
check_command check_mysql!-P 3306
}
Insgesamt ist das Beispiel mit 4 Checks sogar noch recht übersichtlich, vor allem, solang alle Dienste auf einem Host liegen. In diesem Fall ist also eine funktionierende Shop-Seite vom laufenden Webserver und der laufenden Datenbank abhängig. Das Impressum kann natürlich auch nur erreicht werden, solange der Webserver läuft. Daraus ergibt sich dann für die Definition der Abhängigkeiten folgende Ergänzung in der Konfigurationsdatei:
define servicedependency{
host_name WEBSERVER
service_description HTTP
dependent_service_description HTTP-IMPRESSUM,HTTP-SHOP
execution_failure_criteria n
notification_failure_criteria w,u,c
}
define servicedependency{
host_name WEBSERVER
service_description MYSQL
dependent_service_description HTTP-SHOP
execution_failure_criteria n
notification_failure_criteria w,u,c
}
Ein kleiner Fallstrick war bei mir, dass ich zwischen den Services in der Zeile dependent_service_description bei den kommagetrennten Services ein Leerzeichen zwischen den einzelnen Services hatte und dadurch (zumindest auf meinem Testsystem) keine Serviceabhängigkeit erkannt wurde. Durch execution_failure_criteria n
wird der Check jederzeit ausgeführt, so dass man auch über die Verfügbarkeitsreports die Verfügbarkeit der einzelnen Checks (HTTP-SHOP, HTTP-IMPRESSUM
) zuverlässige und realitätsgetreue Reports erstellen kann.
Auch wenn Services über verschiedene Hosts verteilt sind, können Serviceabhängigkeiten über die Hosts hinweg definiert werden. Wenn die MySQL-Datenbank also auf dem Host DB-SERVER
liegt, würde die Abhängigkeit für den Shop also wie folgt aussehen:
define servicedependency{
host_name DB-SERVER
service_description MYSQL
dependent_host_name WEBSERVER
dependent_service_description HTTP-SHOP
execution_failure_criteria n
notification_failure_criteria w,u,c
}
Mit wenig Aufwand lässt sich so relativ leicht der Wust von Benachrichtigungen auf ein überschaubares Maß reduzieren.
Serviceabhängigkeiten gibt es in Nagios seit der Version 3 sowie in Icingin der Version 1.0.x. Die URL zur Dokumentation von Host- und Serviceabhängigkeiten ist in der Installation: $IcingaURL/docs/de/dependencies.html