Für alle Anwendungen hinterlegt der Administrator außerdem die in den SLAs vereinbarten Verfügbarkeits-Grenzwerte, die Onlinezeiten oder etwa die maximal tolerierbare Ausfallzeit. Bei Anwendungen, für die es keine expliziten Service Level Agreements gibt, schreibt er am besten die Zeiten auf, in denen der Nutzer normalerweise erwartet, dass die Anwendung zur Verfügung steht. Als Nächstes fasst er alle Komponenten jeder Anwendung in einem Strukturdiagramm zusammen. Dabei ist es wichtig, die Zusammenhänge aufzuzeichnen, also etwa vorhandene Redundanzen und Verknüpfungen.
Abbildung 1: Infrastruktur-Diagramm eines Webshops mit Loadbalancer und Webserver. Alle wichtigen Komponenten sind doppelt vorhanden, fällt eine aus, steht die Anwendung dennoch zur Verfügung.
Abbildung 2: Infrastruktur-Diagramm eines Mailservers. Hier sind die Internetverbindung und die Mail-Gateways redundant ausgelegt.
Abbildung 3: Infrastruktur-Diagramm eines Intranetportals. Die Verfügbarkeit der einzelnen Server ist hier ausreichend gegeben.
Strukturdiagramme
An dieser Stelle lohnt es sich, etwas mehr Zeit aufzuwenden und sehr gewissenhaft zu sein, denn die resultierende Geschäftsprozess-Überwachung kann nur so gut sein, wie die in diesem Schritt erstellten Infrastruktur-Diagramme (Abbildungen 1 bis 3). Diese Sorgfalt verhindert, dass Nagios später eine Anwendung als nicht verfügbar darstellt, obwohl sie – etwa wegen nicht abgebildeter Redundanz – eigentlich doch funktioniert. Noch fataler wäre der umgekehrte Fall: Weil der Planer in der Konzeptionsphase eine Komponente vergaß, meldet das Monitoring »OK« und alarmiert niemanden, obwohl keiner arbeiten kann.
Als Nächstes sind für jede Komponente die Messpunkte (Nagios nennt sie Services) festzulegen. Bei einem Webserver zum Beispiel ist es offensichtlich sinnvoll, den Seitenabruf via HTTP zu testen: Kommt auf den entsprechenden Request eine sinnvolle Antwort (etwa »HTTP 200 OK« oder »HTTP 302«) in akzeptabler Zeit zurück, lautet das Ergebnis »OK« (grün). Kommt eine sinnvolle Antwort, allerdings langsam, dann ist »Warning« (gelb) das Ergebnis, kommt gar keine Antwort oder eine Fehlermeldung (beispielsweise bei HTTP Return-Codes ab 500), ist der Check fehlgeschlagen (»Critical«, rot).
Andere Messpunkte sind nicht ganz so simpel auszuwerten, können aber oft Hinweise auf sich anbahnende Probleme geben, weshalb man sie auf jeden Fall einbeziehen sollte.
Um herauszufinden, welche der weniger offensichtlichen Messpunkte sinnvoll sind, hat es sich bewährt, darüber nachzudenken, welche Ursachen in der Vergangenheit zu Problemen führten. Genau diese Ursachen sollte das Monitoring im Auge behalten. Die Messpunkte baut der Admin dann im täglichen Betrieb sukzessive weiter aus, indem er sich bei jeder neuen Störung fragt: Hätten ich das Problem vorher erkennen können? Falls ja: Welche Informationen wären dafür nötig gewesen? Auf genau diese Information setzt er dann einen neuen Messpunkt.
Umsetzung
Anschließend geht es an die Umsetzung mit Nagios [1]. Die im Konzept erfassten Komponenten verwandeln sich dabei in ihrer Mehrzahl in Hosts, die Messpunkte in Services. Für jeden Service benötigt Nagios ein Plugin, das die gewünschten Informationen liefert. Eine gute Anlaufstelle für Plugins fast aller Anwendungsbereiche ist Nagiosexchange [2]. Findet sich dort wirklich nichts, bleibt immer noch das Entwickeln eines eigenen Plugins. Die Schnittstelle [3] ist so einfach, dass sich grundsätzlich jede Sprache eignet. Eine Einführung in die Programmierung von Nagios-Plugins in Perl geben [4] und [6].
Im nächsten Schritt geht es darum, die Verfügbarkeit aller Anwendungen zu visualisieren und Statistiken auf Anwendungsebene zu erzeugen. Das leistet das Addon “Nagios Business Process View and Nagios Business Impact Analysis”. Als Voraussetzung sind zunächst die NDO-Utils von [1] zu installieren. Sie dienen dazu, alle Statusinformationen von Nagios in einer MySQL-Datenbank abzulegen. Diese Datenbank ist die offizielle Schnittstelle für Statusabfragen, bei der sich auch das Plugin Nagios Business Process View bedient.
