Geschäftsprozesse mit Nagios und check_multi auf Herz und Nieren prüfen

28. Mai 2009 | Von | Kategorie: Monitoring | Availability

Die Überwachung netzwerkbasierter oder lokaler Ressourcen von Systemen ist ein Leichtes. Dennoch ist hiermit bei weitem nicht die Grenze des Möglichen von Nagios und seinen AddOns erreicht. In diesem Artikel will ich das grundlegende Vorgehen des Business Process Monitoring erläutern und an einem einfachen Beispiel vorführen.

Doch zunächst einige Grundlagen. Mit Business Process werden geschäftliche Abläufe bezeichnet. Beispielsweise stellt die Bestellung eines Buches in einem Online-Shop einen solchen Prozess dar. Der wesentliche Unterschied zum Monitoring von Systemen, ist der, dass das Resultat eines Checks nicht ausschließlich von den einzelnen getesteten Ressourcen  abhängt, sondern eine Mischung aus den Resultaten einzelner Test sein kann. So kann es beispielsweise bei redundant ausgelegten Systemen vorkommen, dass zwar ein Webserver ausgefallen ist, aber der Business Process als solches – durch die Hochverfügbarkeit der Systeme – dennoch garantiert ist. Business Process Monitoring ist daher eine optimale Ergänzung zur Überwachung von Geschäftsprozessen, die die getesteten Systeme in unterschiedlichen Kombinationen voraussetzen.

Extra einen Webshop zur Demonstration aufzusetzen, wäre ein wenig übertrieben ;-). Daher prüfen wir die grundlegende Funktionialtät dieses Blogs. Die grundlegende Funktionalität ist also dann garantiert, wenn Webserver und Datenbank laufen und eine erfolgreiche Anmeldung am Blog möglich ist. Der Geschäftsprozess ist in diesem Falle eine Anmeldung am Blog. Selbst wenn der Webserver und auch die Datenbank korrekt laufen, heißt das noch lange nicht, dass auch die Webanwendung korrekt funktioniert ;-).  Dieses ist ein simples Beispiel, soll aber im wesentlichen die Funktionalität von check_multi verdeutlichen. Ist das grundlegende Prinzip erstmal verstanden, ist die Übertragung auf die eigenen Geschäftsprozesse eine reine Transferleistung. Im Beispiel gehen wir auch noch davon aus, dass Webserver und Datenbank auf unterschiedlichen Systemen liegen.

Das Plugin check_multi fasst zunächst einige Tests zusammen und ermöglicht hierdurch überhaupt die grundlegende Funktionalität für das Business Process Monitoring – nicht nur für Webanwendungen.

command [ mysql ]=/usr/lib/nagios/plugins/check_mysql -H <IP DB> -u <user>> -p <kennwort>
command [ http ]=/usr/lib/nagios/plugins/check_http -H <IP Webserver>
command [ login ]=/usr/lib/nagios/plugins/check_login <username> <passwd> <url>
Schematische Darstellung der IT-Struktur der Beispiel-Webanwendung

Schematische Darstellung der IT-Struktur der Beispiel-Webanwendung

Um eine redundante IT-Struktur zu demonstrieren, ergänze ich die check_multi-Konfiguration noch ein paar Dummy-Checks. Diese Checks kann ich später auch bestens zum Testen der logischen Verknüpfung der Geschäftsprozesse verwenden. Allgemein ist dies ein guter Weg um komplexere logische Verknüpfungen der Testresultate wirklich zu testen, in dem mittels check_dummy entsprechende Resultate vorgegeben werden. Stimmt die Logik, dann können die Dummy-Tests durch die korrekten Tests ersetzt werden.

command [ dummy-http1 ] =/usr/lib/nagios/plugins/check_dummy 0
command [ dummy-http2 ] =/usr/lib/nagios/plugins/check_dummy 0
command [ dummy-http3 ] =/usr/lib/nagios/plugins/check_dummy 0
command [ dummy-http4 ] =/usr/lib/nagios/plugins/check_dummy 0

Zunächst sehen wir uns das Ergebnis im Nagios-Webinterface an, wenn alles in Ordnung ist.

check_multi - Alles Tests in Ordnung

check_multi - Alles Tests in Ordnung

Im Falle meines Beispiels soll nur dann ein fehlerhaftes Resultat ausgegeben werden, wenn entweder die Datenbank nicht erreichbar, ein Login nicht erfolgreich durchgeführt werden konnte oder alle Webserver ausgefallen sind. Fallen alle bis auf ein Webserver aus, so sollte der Business Process weiterhin einen OK-Status aufweisen, schließlich ist der Geschäftsprozess auch (noch) nicht von den Ausfällen betroffen. Nutzen wir einen der Dummy-Tests und setzen ihn auf ein fehlerhaftes Ergebnis (check_dummy 2):

check_multi - Ohne Business Process

check_multi - Ohne Business Process

Nun ist dieser aber genau ein Fall, den ich durch das Business Process Monitoring verhindern wollte. Also ran an die Konfiguration. Ein manueller Aufruf von check_multi mit dem Parameter -v gibt ausführlichere Informationen aus und gibt immer nützliche Hinweise, warum eigentlich welcher Status ausgegeben wurde.

$ /usr/lib/nagios/plugins/check_multi -f check.cmd -v

--------------------------------------------------------------------------------
Plugin output
--------------------------------------------------------------------------------
CRITICAL - 7 plugins checked, 1 critical (dummy-http1), 6 ok [http perfdata discarded for time: bad UOM ',' in data '0,004000s;;;0,000000' time: bad min '0,000000' in data '0,004000s;;;0,000000' ]
[ 1] mysql Uptime: 7170  Threads: 1  Questions: 5677  Slow queries: 0  Opens: 46  Flush tables: 1  Open tables: 40  Queries per second avg: 0.792
[ 2] http HTTP OK - HTTP/1.1 302 Found - 0,004 second response time
[ 3] login Login correct - OK
[ 4] dummy-http1 CRITICAL
[ 5] dummy-http2 OK
[ 6] dummy-http3 OK
[ 7] dummy-http4 OK

...

--------------------------------------------------------------------------------
State    Expression                                              Evaluates to
--------------------------------------------------------------------------------
OK       1                                                       TRUE
UNKNOWN  COUNT(UNKNOWN)>0                                        FALSE
WARNING  COUNT(WARNING)>0                                        FALSE
CRITICAL COUNT(CRITICAL)>0                                       TRUE
--------------------------------------------------------------------------------
Overall state => CRITICAL
--------------------------------------------------------------------------------
|check_multi::check_multi::plugins=8 time=0.644000

Jetzt erklärt sich auch, weshalb wir einen kritischen Zustand erhalten, wenn bereits ein Webserver ausfällt. Sobald ein Test einen kritischen Zustand zurückgibt, wird der Gesamtzustand als kritisch betrachtet. Die oben aufgeführten States sind immer implizit gültig und sind im Fall der Fälle entsprechend zu überschreiben.  Ich kann diesen Gesamtstatus aktiv beeinflussen, in dem ich die States selbst in Abhängigkeit der Testresultate definiere. Zunächst sorge ich dafür, dass nur bei Ausfall oder Nichterreichbarkeit aller Webserver ein kritischer Zustand ausgegeben wird.

Die States werden ebenfalls in der Konfigurationsdatei für check_multi konfiguriert. Daher ergänze ich diese um folgenden Eintrag:

state [ critical ] = ( http > 0 && dummy-http1 > 0 && dummy_http2 > 0 && dummy-http3 > 0 && dummy-http4 > 0 )

Ein manueller Aufruf bringt folgendes Ergebnis:

$ /usr/lib/nagios/plugins/check_multi -f check.cmd -v

--------------------------------------------------------------------------------
Plugin output
--------------------------------------------------------------------------------
OK - 7 plugins checked, 1 critical (dummy-http1), 6 ok [http perfdata discarded for time: bad UOM ',' in data '0,004000s;;;0,000000' time: bad min '0,000000' in data '0,004000s;;;0,000000' ]
[ 1] mysql Uptime: 8331  Threads: 1  Questions: 6716  Slow queries: 0  Opens: 46  Flush tables: 1  Open tables: 40  Queries per second avg: 0.806
[ 2] http HTTP OK - HTTP/1.1 302 Found - 0,004 second response time
[ 3] login Login correct - OK
[ 4] dummy-http1 CRITICAL
[ 5] dummy-http2 OK
[ 6] dummy-http3 OK
[ 7] dummy-http4 OK

...

--------------------------------------------------------------------------------
State    Expression                                              Evaluates to
--------------------------------------------------------------------------------
OK       1                                                       TRUE
UNKNOWN  COUNT(UNKNOWN)>0                                        FALSE
WARNING  COUNT(WARNING)>0                                        FALSE
CRITICAL ( http > 0 && dummy-http1 >0 && dummy_http2>0 && dummy-http3 >0 &&; dummy-http4 >0 ) FALSE
--------------------------------------------------------------------------------
Overall state => OK
--------------------------------------------------------------------------------
|check_multi::check_multi::plugins=8 time=0.628000

Der dummy-http1-Test liefert zwar weiterhin ein kritisches Testresultat, aber ich habe durch die State-Definition den kritischen Gesamtzustand neu definiert. Für die bereits oben aufgeführten Anforderungen müsste ich folgende States definieren.

state [ critical ] = (( http &amp;gt; 0 &amp;amp;&amp;amp; dummy-http1 &amp;gt; 0 &amp;amp;&amp;amp; dummy-http2 &amp;gt; 0 &amp;amp;&amp;amp; dummy-http3 &amp;gt; 0 &amp;amp;&amp;amp; dummy-http4 &amp;gt; 0) || ( mysql &amp;gt; 0 || login &amp;gt; 0 ))

Nach einem bewußt herbeigeführten „Fehler“ der Datenbank, wird der folgende Test wieder zu einem kritischen Gesmatzustand führen.

/usr/lib/nagios/plugins/check_multi -f check.cmd -v

--------------------------------------------------------------------------------
Plugin output
--------------------------------------------------------------------------------
CRITICAL - 7 plugins checked, 3 critical (mysql, login, dummy-http1), 4 ok [http perfdata discarded for time: bad UOM ',' in data '0,000000s;;;0,000000' time: bad min '0,000000' in data '0,000000s;;;0,000000' ]
[ 1] mysql Can't connect to MySQL server on '127.0.0.1' (111)
[ 2] http HTTP OK - HTTP/1.1 302 Found - 0,000 second response time
[ 3] login Login incorrect - CRITICAL
[ 4] dummy-http1 CRITICAL
[ 5] dummy-http2 OK
[ 6] dummy-http3 OK
[ 7] dummy-http4 OK

...

--------------------------------------------------------------------------------
State    Expression                                              Evaluates to
--------------------------------------------------------------------------------
OK       1                                                       TRUE
UNKNOWN  COUNT(UNKNOWN)>0                                        FALSE
WARNING  COUNT(WARNING)>0                                        FALSE
CRITICAL (CRITICAL ( http > 0 && dummy-http1 >0 && dummy_http2>0 && dummy-http3 >0 &&; dummy-http4 >0 ) || ( mysql > 0 || login > 0 )) TRUE
--------------------------------------------------------------------------------
Overall state => CRITICAL
--------------------------------------------------------------------------------
|check_multi::check_multi::plugins=8 time=0.212000

Ebenso wird der Business Process im Falle eines Ausfalles aller Webserver reagieren.

check_multi - Business Process Monitoring

check_multi - Business Process Monitoring

Das Plugin check_multi, kann sowohl zählen, als auch logische Verknüpfungen von Testresultaten vornehmen. Dies kann zur Definition der einzelnen States genutzt werden. Genaugenommen können alle logischen Perl-Ausdrücke verwendet werden.

Also dann viel Spaß und Erfolg beim Monitoren eurer Geschäftsprozesse.

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Ping.fm Post to Reddit

Tags: | | |

Schreibe einen Kommentar

Fühle dich ermuntert einen Kommentar, Anmerkungen, Hinweise oder deine Ideen zum Thema zu hinterlassen. Wir freuen uns über deine Rückmeldung.