© NASA

Admins interessiert beim Monitoring, welche Komponente gerade Probleme bereitet. Das Management oder die Kunden benötigen dagegen eher eine Ansicht, die Auswirkungen eines Ausfalls verdeutlicht. Nagios kann auch diese Perspektive visualisieren – das richtige Addon vorausgesetzt.

Wer IT-Dienstleistungen anbietet – sei es für Kunden oder für Mitarbeiter -, ist immer öfter mit dem Thema Service Level Agreements (SLA) konfrontiert (siehe Kasten “Service Level Agreements”). Solche Zielvereinbarungen wären ohne Überwachung nutzlos. Im ungünstigsten Fall ist der Anwender die erste und einzige Monitoring-Komponente, die sich mit einem Problem an die Hotline wendet. Der Administrator kann in diesem Fall erst im Nachhinein damit beginnen, das Problem zu analysieren und nach einer Lösung zu suchen.

Komponenten-Monitoring

Unternehmen, die ihren Anwendern einen besseren Service bieten wollen, verwenden Monitoring-Systeme, die ihre Server, Router, Switches, WAN-Strecken, und so weiter überwachen. Oft kommen dabei funktionale Tests zum Einsatz, die beispielsweise HTTP-Requests an einen Webserver schicken und die Antwortzeit messen sowie die HTTP-Fehlercodes auswerten. Verlängert sich die Bedenkzeit des Servers oder häufen sich die Fehler, schlägt das System Alarm.

Dadurch bemerkt der Administrator frühzeitig Probleme, die sich ankündigen, und kann dem hohen Besucherandrang auf seiner Internetpräsenz oder dem volllaufenden Filesystem mit geeigneten Maßnahmen begegnen, bevor seine Anwender in die Bredouille geraten.

Komponenten-Monitoring dieses Zuschnitts hilft dabei, Probleme zu vermeiden oder zumindest schnell zu lokalisieren. Bei der Überwachung von Service Level Agreements stößt es allerdings an seine Grenzen. Viele der Tools können zwar auf Ebene einzelner Komponenten Reports generieren oder Verfügbarkeitszahlen für einen bestimmten Zeitraum liefern, die Anwendung aber, auf die sich das SLA bezieht, besteht in der Regel aus mehreren Komponenten. Deren Verfügbarkeit lässt sich nicht ohne Weiteres durch einfache Addition einzelner Ausfallzeiten ermitteln. Überschneiden sich Störungen oder arbeitet ein redundanter Verbund weiter, obwohl einzelne Komponenten ausgefallen sind, dann könnte das einfache Zusammenzählen zu falschen Ergebnissen führen.

Robots

Einen anderen Ansatz verfolgt das Monitoring aus Kundensicht. Dabei bedient eine Robot-Software die zu überwachende Anwendung genau so, wie dies ein Anwender täte. Der Robot arbeitet eine einmal aufgezeichnete Schrittfolge ab, zeichnet die Antwortzeiten auf und prüft, ob sich die erwarteten Resultate einstellen. Diese Art der Überwachung liefert alle Kennzahlen, die zur Bewertung von SLAs nötig sind. Sie hat aber auch einen Nachteil: Sie informiert nur darüber, dass die Anwendung nicht verfügbar ist oder zu langsam antwortet, verrät aber nicht, welche Komponente das Problem verursacht.

Bei kleineren Anwendungen mit nur wenigen Komponenten funktioniert die Lokalisierung des Fehlers meist trotzdem, vor allem wenn ein erfahrener Administrator aus dem Verhalten der Anwendung Rückschlüsse auf die Ursache zieht. Bei einer komplexeren Anwendung, die vielleicht sogar redundant ausgelegt ist und aus Dutzenden Einzelkomponenten besteht, ginge mit dieser Methode allerdings viel Zeit verloren, bis die Ursache entdeckt wäre.

Geschäftsprozesse

Optimal wäre eine Lösung, die sowohl eine Sicht auf die Einzelkomponenten zulässt als auch den Status der kompletten Anwendung darstellt. Zur schnellen Fehlerlokalisierung sollte es außerdem möglich sein, in der Darstellung des Monitors von der Anwendung bis zur ausgefallenen Komponente abzusteigen (Drill-down). Eine solche kombinierte Strategie ist mit Nagios – die richtigen Addons vorausgesetzt – möglich.

Noch vor der Installation irgendwelcher Nagios-Addons empfiehlt es sich jedoch, die Anwendungen, die das Monitoring beobachten soll, genauer unter die Lupe zu nehmen und ein Konzept zu erstellen. Das kann zum großen Teil in Form schematischer Darstellungen geschehen, wie etwa im folgenden Beispiel, bei dem ein Webshop (siehe Abbildung 1), ein Mailserver (Abbildung 2), ein ERP-System als Kernsystem sowie ein Intranetportal für die Mitarbeiter (Abbildung 3) zu beobachten sind.

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.

Das Addon ist auf [5] erhältlich. Seine Installation beschreiben mitgelieferte Install- beziehungsweise Readme-Files. Die Datei »nagios-bp.conf« bildet die Anwendungen ab, die der Admin in der Konzeptphase durch die Infrastruktur-Diagramme dargestellt hat. Das mitgelieferte Muster enthält Beispiel-Konfigurationen, die jetzt durch eigene Vorgaben zu ersetzen sind.

Ziel ist es, jede im Konzept erwähnte Anwendung als einen Businessprozess abzubilden, indem man einzelne Nagios-Services miteinander verknüpft. Die wichtigsten Verknüpfungstypen sind dabei »UND« (alle genanten Services müssen verfügbar sein, damit der Businessprozess verfügbar ist) sowie »ODER« (mindestens einer der genannten Services muss funktionieren, damit der Businessprozess funktioniert). Da ein solcher Prozess selbst auch Teil eines anderen Geschäftsprozesses sein darf, lassen sich baumartige Strukturen aufbauen, die eine Anwendung abbilden. »UND«-Verknüpfungen geben dabei den schlechtesten Status aller ihrer Komponenten nach oben weiter, »ODER«-Verknüpfungen den besten.

Geschäftsprozesse definieren

Das folgende Beispiel, das sich an der Beispielkonfiguration orientiert, die das Addon mitliefert, illustriert die Vorgehensweise. Zunächst trägt der Anwender einige Geschäftsprozesse ein, die später andere Businessprozesse verwenden sollen (Listing 1, Zeilen 1 bis 10). Das Beispiel geht davon aus, dass in Nagios Hosts mit den Namen »loadbalancer1« und »loadbalancer2« definiert sind. Auf jedem der beiden Hosts ist ein Service namens »System Health« eingerichtet. Zeile 3 definiert einen Businessprozess »loadbalancers«, der aus den beiden genannten Services besteht, die das Oder-Symbol »|« verknüpft.

01  # base components
02 
03 loadbalancers = loadbalancer1;System Health | loadbalancer2;System Health
04 display 0;loadbalancers;Loadbalancer Cluster
05 
06 dns = dns1;DNS | dns2;DNS | dns3;DNS
07 display 0;dns;DNS Cluster
08 
09 internetconnection = internetconnection;
   Provider 1 | internetconnection;Provider 2
10 display 0; internetconnection;Internet Connection
11 
12 # ERP System
13 
14 erp_system = erp;System Check & db;Select & dns
15 display 3;erp_system;ERP System
16 info_url erp_system;http://monitoring.some.org/handlungsanweisungen/erp.html
17 external_info erp_system;/usr/local/bin/info_erp.sh
18 
19 # BP Webshop
20 
21 webshop_frontend_line1 = webserver1;
   HTTPS & appserver1;HTTP
22 webshop_frontend_line2 = webserver2;
   HTTPS & appserver2;HTTP
23 webshop_frontend = webshop_frontend_line1 | webshop_frontend_line2
24 webshop = internetconnection & loadbalancers & dns & webshop_frontend & erp_system
25 
26 display 0;webshop_frontend_line1;
   WebShop Frontend Servers Line1
27 display 0;webshop_frontend_line2;
28 WebShop Frontend Servers Line2
29 display 0;webshop_frontend;
   WebShop Frontend Servers
30 display 1;webshop;WebShop
31 info_url webshop;http://monitoring.some.org/handlungsanweisungen/webshop.html
32 external_info webshop;/usr/local/bin/info_webshop.sh
33 
34  # BP eMail
35 
36 mailgateways = mailgateway1;
   SMTP | mailgateway2;SMTP
37 mail = internetconnection & dns &
   mailgateways & groupwareserver;SMTP &
   groupwareserver;IMAP & groupwareserver;
   GroupDAV & groupwareserver;HTTPS
38 
39 display 0;mailgateways;Mail Gateways
40 display 2;mail;eMail
41 info_url mail;http://monitoring.some.org/
   handlungsanweisungen/mail.html
42 
43 # BP Intranet Portal
44 
45 intranetportal = intranetwebserver;HTTPS & intranetwebserver;HTTPD Slots &
   intranetportalserver;HTTP & erp_system
46 display 3;intranetportal;Intranet Portal
47 external_info intranetportal;
  /usr/local/bin/info_intranet_portal.sh
48 info_url intranetportal;
   http://monitoring.some.org/handlungsanweisungen/intranetportal.html

Hier handelt es sich also offenbar um redundant ausgelegte Komponenten (Abbildung 1). Es reicht daher, wenn einer der beiden Host-Checks den Status »OK« meldet, damit der gesamte Businessprozess den Status »OK« erhält.

Das Schlüsselwort »display« in Zeile 4 ordnet dem gerade definierten Prozess eine Beschreibung zu, die später die Browseroberfläche anzeigt. Die Ziffer Null sagt aus, dass dieser Prozess auf oberster Ebene gar nicht auftaucht, es handelt sich also um einen reinen Sub-Prozess, der lediglich in anderen Prozessen Verwendung findet. Die Zeilen 6 und 7 definieren auf die gleiche Weise einen Businessprozess »dns«, der aus drei Services besteht.

Der erste, auch auf oberster Ebene sichtbare Prozess ist das Intranetportal (Abbildung 3) – ihn definiert Zeile 45. Er besteht aus den Services HTTPS und HTTPD, Slots auf dem Host »intranetwebserver«, dem Service HTTP auf »intranetportalserver« und dem Businessprozess »erp_system«, den bereits Zeile 14 weiter oben einführte. Die Komponenten sind über das »&«-Symbol verknüpft. Laut Infrastruktur-Diagramm muss das auch so sein, denn alle Komponenten sind nötig, damit die Anwendung funktioniert.

Der Geschäftsprozess bekommt den Status der Komponenten, die das Monitoring am schlechtesten beurteilt. Wenn also nur eine »Critical« meldet, erhält die gesamte Anwendung den Status »Critical«. Bei den Definitionen der Komponenten für den Businessprozesse ist die Reihenfolge wichtig, weil jeder Prozess vor seiner Verwendung in der Konfigurationsdatei zu beschreiben ist.

Gliedern mit Prioritäten

Im »display«-Statement in Zeile 46 bekommt der Prozess die Priorität 3 zugeordnet. Man kann entweder allen Prozessen die gleiche Priorität geben (dann normalerweise die 1), damit die oberste Ebene alle Prozesse gleichwertig darstellt. Alternativ vergibt der Admin unterschiedliche Prioritäten (1 bis n, es lassen sich beliebig viele verwenden) – dann erscheint die Ansicht besser strukturiert, was ab einer gewissen Anzahl von Anwendungen sehr sinnvoll ist (Abbildung 5).

Wenn die Konfiguration so weit funktioniert, kann der Anwender die Nagios Business Process View erstmals im Browser aufrufen, wie in Abbildung 4 zu sehen, allerdings mit erst einer Anwendung. Über eine »external_info«-Anweisung (Zeile 47) lässt sich jedem Businessprozess auf oberster Ebene ein kurzer Text zur Darstellung in der rechten Spalte zuweisen. Ihn generiert ein Skript, das so aufgebaut sein muss, dass es genau eine Zeile auf Stdout ausgibt. Diese Zeile wird dann angezeigt. Damit ist es beispielsweise möglich, aktuelle Kennzahlen über die Auslastung (etwa User-Sessions) anzuzeigen.

Mit der Anweisung »info_url« lässt sich jedem Business Prozess eine URL zuordnen. Ist sie definiert, erscheint neben dem Status der Anwendung ein kleines weißes »i« auf blauem Hintergrund. Klickt der User auf dieses Icon, wechselt der Browser zur angegebenen URL. Dort können weiterführende Informationen oder Hinweise zur Problembehebung hinterlegt sein. Auch die Kernpunkte der SLAs lassen sich hier ablegen.

Abbildung 4: Geschäftsprozess-Überwachung mit Nagios und dem Addon Nagios Business Process View.

Abbildung 5: Betriebsüberwachung im Rechenzentrum der Sparda-Datenverarbeitung, unter anderem mit Nagios und dem Addon Business View.

Anwendersicht

Weitere Anwendungen modelliert man nach dem Vorbild der ersten. Insgesamt entsteht eine Ansicht wie in Abbildung 4 gezeigt. Über das Baum-Icon ist ein Drill-down durch die verschiedenen Ebenen bis hinab zur einzelnen Komponente möglich. Ist eine Anwendung im Status »Critical«, muss der Anwender zur schnellen Fehlerlokalisierung einfach nur auf jeder Ebene das rote Element anklicken, bis er bei der verursachenden Komponente landet.

Ist es für den User im Moment gar nicht wichtig, wie die einzelnen Komponenten miteinander verknüpft sind, kann er auch eine flache Komponentenliste (mit aktuellem Status) je Anwendung abrufen. Damit durch kurzzeitige Problemen mit einzelnen Komponenten keine Flackerzustände entstehen, verwendet die Business Process View ausschließlich Hard-States von Nagios.

Redundanz modellieren

Eine mögliche Gefahrenquelle besteht bei der Modellierung redundanter Systeme. Den Webshop (Abbildung 1) sollte man nicht etwa so modellieren:

websrv = webserver1;HTTPS | webserver2;HTTPS
appsrv = appserver1;HTTP | appserver2;HTTP 
webshop = internetconnection & loadbalancers & dns & websrv & appsrv &erp_system

Dieses Vorgehen hat nämlich zur Folge, dass bei einem gleichzeitigen Ausfall von »webserver1« und »appserver2« die Anwendung noch als verfügbar dargestellt würde. Wie das Infrastruktur-Diagramm jedoch zeigt, ist »webserver1« fest mit »appserver1« verdrahtet und »webserver2« ebenso mit »appserver2«. Es wären also beide Linien unterbrochen und die Anwendung stünde dem Kunden im Ergebnis nicht mehr zur Verfügung. Richtig wäre dagegen in diesem Fall eine Modellierung, wie sie Listing 1 in den Zeilen 21 bis 24 darstellt.

Hat der Admin eine bestimmte Komponente aus Lastgründen mehrfach ausgelegt, kann er auch dies abbilden. Die Konfiguration

app = 3 of:appserver1;HTTP + appserver2;U
HTTP + appserver 3;HTTP + appserver4;HTTP

gilt beispielsweise für einen gut besuchten Webshop mit vier Application-Servern, von denen mindestens drei verfügbar sein müssen, damit keine Performance-Probleme auftreten.

HTTP-Statistiken und Alarmierung

Wie gezeigt, kann das Addon einen Blick auf den aktuellen Status der definierten Anwendungen liefern. Doch das Tool kann noch mehr. Ein mitgeliefertes Skript integriert alle Businessprozesse ihrerseits als Services in Nagios, wodurch das Monitoring-Tool sie in regelmäßigen Abständen abfragt. Damit stehen für die Businessprozesse alle Möglichkeiten bereit, die Nagios zur Verfügung stellt: Es lassen sich beispielsweise Verfügbarkeitsstatistiken für frei definierbare Zeiträume erstellen und es ist auch möglich, Alarme für komplette Anwendungen zu hinterlegen.

Diese Alarme sind selbstverständlich auch kombinierbar. Dann erhält einerseits der Admin weiterhin Meldungen für die jeweils betroffene Komponente, was ihm die Fehlersuche erleichtert. Gleichzeitig kann Nagios aber beispielsweise einen Vorgesetzten via E-Mail gezielt über den Ausfall einer kritischen Anwendung informieren, der eine Folge des Komponentenausfalls ist.

Impact-Analyse:Was wäre wenn?

Die zweite Teilkomponente des Addons, die Nagios Business Impact Analyse, bietet ebenfalls eine interessante Funktion: die Was-wäre-wenn-Analyse. Was würde passieren, wenn jetzt »Webserver1« ausfiele? Welche Auswirkungen hätte das auf die Kunden? Was wäre, wenn der SMTP-Dienst auf »Mailgateway1« stoppte? Die Business Impact Analyse arbeitet auf Basis derselben Geschäftsprozesse wie die Business Process View, nur mit dem Unterschied, dass hier der User über das Webfrontend die Status einzelner Hosts oder Services gezielt auf beliebige Werte setzen kann.

Das ermöglicht die Simulation beliebiger Ausfall-Szenarien und die Analyse der potenziellen Auswirkungen auf den Geschäftsbetrieb. Nachdem der Admin den Status jeder Komponente so eingestellt hat, wie es dem zu testenden Szenario entspricht, kehrt er auf die oberste Ebene zurück, die die Auswirkungen darstellt. Die Weboberflächen der beiden Teile des Addons unterscheiden sich ansonsten nicht.

Praxis

Dass der Admin mit den in diesem Beitrag skizzierten Verfahren und den beschriebenen Tools seine Geschäftsprozesse tatsächlich erfolgreich im Griff haben kann, das zeigt der derzeit wohl größte Praxiseinsatz des Addons bei der Sparda-Datenverarbeitung, einem großen deutschen Banken-Rechenzentrum (Abbildung 5). Die Admins dort managen auf diese Weise so extrem wichtige Dienste wie beispielsweise das Homebanking via Internet.

Kombiniert

Doch bekanntlich ist ja nichts so gut, dass es nicht noch zu verbessern wäre. Das stimmt auch in diesem Fall. In der Praxis zeigen sich nämlich immer wieder – wenn auch sehr selten – Fälle, in denen alle beteiligten Komponenten einzeln funktionieren, die gesamte Anwendung aber trotzdem nicht verfügbar ist. Daher kombiniert die Premium-Klasse beim Monitoring die eingangs erläuterten beiden Ansätze: Ein Monitoring aus Kundensicht gibt in diesem Fall eindeutig darüber Auskunft, ob eine Anwendung funktioniert oder nicht. Ein zweiter Überwachungsprozess auf der Grundlage der Komponentensicht, der auch die Visualisierung der Geschäftsprozesse übernimmt, hilft dann parallel dazu im Problemfall bei der schnellen Lokalisierung der Fehlerursache. (jcb)