Das klassische Monitoring arbeitet mit einer Reduzierung aller zu monitorenden Bereiche auf kleine, unabhaengige Einheiten. Mit diesen Einheiten fuettert man dann die Monitoring-Konfiguration: Disks, Prozesse, Datenbanken, Log-Messages, etc. etc.

Das grundlegende Problem einer solchen Vorgehensweise liegt darin, dass die kleinen Einheiten ihren Zusammenhang verlieren. Es ist nicht mehr offensichtlich, das die Disk zur Applikation gehoert, dass das Datenbank-Problem der Hauptgrund fuer die Fehlfunktion der Applikation ist und dass der fehlende Daemon die Kommunikation verhindert.

An diesem Punkt kommen die Business Process Views ins Spiel: sie sind ein grundlegender Mechanismus, um eine umfassende Sicht auf die unterschiedlichen Parameter und Eigenschaften eines Prozesses zu bieten und dabei ihre Zusammenhaenge zu erhalten.

Dieses Beispiel beschreibt das Monitoring einer ueblichen Web-Applikation, wie sie in jeder Firma zu finden ist. Diese Applikation laeuft auf einem *nix-Server unter einem Apache Web-Server, verwendet eine MySQL-DB zur Datenhaltung und bietet ihre Inhalte im Intranet an. So weit - so gut.

Sollten Sie hier etwas wichtiges vermissen: zahlreiche Monitoring-Attribute wurden hier bewusst weggelassen, um das Beispiel einfacher zu gestalten

• Monitoring matrix:

Nun ist der Aufbau der cmd-Datei geradezu ein Kinderspiel:

• Datei myapp.cmd:

#--- Web-Applikation myapp
command [ sys_ping   ] = check_icmp -H myhost
command [ sys_load   ] = check_load -w 3,4,5 -c 6,8,10
command [ sys_disk   ] = check_disk -w 5% -c 2% -p / -p /var -p /opt
command [ web_apache ] = check_procs -c 1: -C httpd
command [ db_mysqld  ] = check_mysql
command [ app_myapp  ] = check_http -H myhost -u http ://myhost/myapp

Das sieht schon recht vielversprechend aus…

nagios@thinkpad ~/libexec> ./check_multi -f myapp.cmd -r 0
WARNING - 6 plugins checked, 0 critical, 1 warning, 0 unknown, 5 ok
[ 1] sys_ping OK - myhost: rta 110.090ms, lost 0%
[ 2] sys_load WARNING - load average: 3.50, 3.40, 3.39
[ 3] sys_disk DISK OK - free space: / 2409 MB (20% inode=81%);
[ 4] web_apache PROCS OK: 11 processes with command name 'httpd2-prefork'
[ 5] db_mysql Access denied for user 'root'@'localhost' (using password: NO)
[ 6] app_myapp HTTP OK - HTTP/1.0 302 Found - 0.290 second response time

• Nun muss sie nur noch in die Nagios-Konfiguration aufgenommen werden.
• Ueblicherweise werden remote Hosts ueberwacht, daher muss noch das Transportmedium (meistens check_nrpe or check_by_ssh) konfiguriert werden.
• Wenn mehr Attribute ueberwacht werden sollen, so ist nur myapp.cmd entsprechend anzupassen und zu erweitern. Wenn erst einmal der Haupt-Service in Nagios konfiguriert ist, so wird auch kein weiterer Neustart benoetigt.
• Auch wenn die Schwellwerte veraendert werden sollen, so ist das kein Problem. Einfach myapp.cmd aendern und die neuen Werte werden nach dem naechsten Intervall automatisch uebernommen.

Um die Funktion einer business-kritischen Applikation sicherzustellen, wird oft auf Cluster-Techniken zurueckgegriffen. Es gibt verschiedene Strategien, um das zu erreichen. Speziell fuer Web-Applikationen ist eine beliebte Methode, eine Server-Farm aufzusetzen, wo eingehende Anfragen auf alle Farm-Rechner verteilt werden. Fuer unser Setup bedeutet das, dass wir das Monitoring auf alle Farm-Rechner erweitern muessen.
Und es gibt einen Unterschied in der Bewertung: Das Endergebnis ist nur dann CRITICAL, wenn alle Farm-Rechner nicht mehr erreichbar sind.

1. Setup des Applikations-Monitoring fuer alle Farm-Rechner.
   Wir koennen myapp.cmd wiederverwenden mit einem kleinen Unterschied: anstelle von myhost sollte localhost verwendet werden. Dann muessen nicht verschiedene Dateien gepflegt werden.
   
   
2. Anlegen eines Master Checks, der pro Host einen Child check enthaelt:
   
   • webapp.cmd (Teil 1):

     command [ myhost1  ] = check_nrpe -H myhost1 -c check_multi -a -f myapp.cmd
     command [ myhost2  ] = check_nrpe -H myhost2 -c check_multi -a -f myapp.cmd

3. Evaluierungs-Logik
   Normalerweise ist der Gesamtstatus CRITICAL, wenn einer der Child-Checks kritisch wird. In unserm Setup kann ein Host durchaus nicht erreichbar sein, ohne dass es die Webapplikation in der Gesamtheit beeintraechtigt. Lediglich der Administrator sollte mitbekommen, dass etwas nicht in Ordnung ist, dies geschieht mit einem WARNING Status.
   
   • webapp.cmd (part 2):

     state   [ CRITICAL   ] = COUNT(CRITICAL) > 1
     state   [ WARNING    ] = COUNT(WARNING) > 0 || COUNT(CRITICAL) > 0

     
     

Das wars auch schon