Open Source im professionellen Einsatz
Linux-Magazin 03/2008
554

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • LTR-Update: Geschäftsprozesse überwachen

    Für die Überwachung von Service Level Agreements (SLAs) ist es wichtig, neben dem Monitoring einzelner Komponenten auch die Funktionsfähigkeit komplexer Prozesse im Blick zu behalten, in die eine Vielzahl von Programmen und Geräten, teils auch redundant eingebunden sind. EIn Nagios Plug-In leistet genau dies.

  • Volle Kontrolle

    Blindflug birgt ein hohes Risiko. In der Luft wie im Rechenzentrum. Hier wie da helfen deshalb Instrumente dabei, rechtzeitig Gefahren zu erfassen. Die verbreiteste freie Software für diesen Zweck ist Nagios, das sich in vielen kleinen wie großen IT-Umgebungen bewährt.

  • Kostenlose Mobil-App für Nagios

    Das schwedische Unternehmen Op5 hat Version 1.0 einer kostenlosen Android-App veröffentlicht, die Monitoring-Daten eines entfernten Nagios-Systems anzeigt.

  • Immer im Dienst

    Service Level Agreements gehören zum lästigen Teil der Admin-Arbeit - wer ihre Einhaltung überprüfen will, muss die Ausfallzeiten von Diensten addieren und je nach Tageszeit bewerten. Eine Nagios-Erweiterung kann das besser und warnt von sich aus, wenn ein Verstoß droht.

  • Open IT Cockpit

    Rechner und deren Dienste überwachen, das übertragen Admins gern an aufmerksame Tools wie Nagios. Ein neues, halbkommerzielles Projekt aus Hessen bündelt und verbirgt alles unter einer Oberfläche.

comments powered by Disqus

Ausgabe 10/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.