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.

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.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

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.