Hier können wir auf einen Blick den Zustand betriebskritischer Anwendungen sehen: Grün = alles in Ordnung, gelb = (noch) unkritische Störung, rot = kritische Störung. Die technische Verfügbarkeit der Systeme ist ebenfalls sichtbar (Up oder Down), wobei ein „Down“ immer auch rot wäre.

Das Dashboard wurde übrigens als Fingerübung von unseren Auszubildenden im ersten Lehrjahr entwickelt – es ist eine JavaScript-Anwendung die sich die Statusinformationen über eine REST-API von einem Applikationsmonitoring-Server abholt – die Aktualisierung erfolgt einmal pro Minute. Ein Fortschrittsbalken zeigt an, dass das Dashboard noch läuft und wann die nächste Aktualisierung erfolgt – Ja, es ist in der Praxis schon vorgekommen, dass der Thin-Client, auf dem die Webanwendung läuft, sich nach mehreren Wochen Dauerbetrieb aufgehängt hatte und die Anwendung eingefroren war. Ist zwar nett, wenn sie im Status „alles Grün“ einfriert, aber nicht ganz im Sinne des Erfinders…

Für das eigentliche Monitoring setzen wir den ManageEngine Applications Manager ein. Dieser bringt bereits eine große Zahl von Sensoren (auch „Monitore“ genannt) out-of-the-box mit, die sofort eingesetzt werden können – z.B. für die Überwachung von CPU-Last und Festplatten-Auslastung. Diese Monitore lassen sich wiederum zu Gruppen zusammenfassen.

Monitore überwachen bei uns neben der technischen Erreichbarkeit auch die auf den Systemen laufenden Services, z.B. über HTTP-Testabfragen.

Die Praxis zeigt: Das reicht nicht.  Denn häufiger als technische Probleme auf Systemebene treten fachliche Fehler in den Anwendungen auf, die eine saubere Prozessverarbeitung verhindern. Z.B. kann es passieren, dass eine eingehende Bestellung von einem Marktplatz, die wir über eine Schnittstelle eines Dienstleisters erhalten haben, unvollständige Daten hat und deswegen nicht verarbeitet werden kann.

Dann gibt es natürlich noch Fehler, die auf Irrtümern in der Entwicklung basieren und beim Test nicht aufgedeckt wurden – wir alle wissen: Vollständige Tests sind nicht möglich. Auch beliebt: Konfigurationsfehler: Ein kleiner Irrtum bei der Änderung der Fact-Finder-Konfiguration für die Suche im Onlineshop (manchmal reicht ein falscher Klick in der Hektik des Tagesgeschäftes) sorgt dafür, dass unsere Kunden leere Kategorieseiten im Shop vorfinden.

Um auch in diesen Fällen Probleme rechtzeitig mitzubekommen, haben wir KPIs eingeführt, die direkt an der Quelle (meist auf unserer ERP-Datenbank) gezählt werden. Beispiel: Wie viele über den Marktplatz Amazon eingegangene Bestellungen sind noch offen (d.h. nicht verarbeitet worden)? Wie viele Retouren sind noch nicht verarbeitet? Aber auch: Wie viele Bestellbestätigungs-Mails haben wir innerhalb einer bestimmten Zeitspanne versendet?

Diese KPIs werden gegen Schwellenwerte auf Plausibilität geprüft und gehen in die Ampel ein: So könnte eine verdächtig geringe Zahl von gesendeten Bestellbestätigungen auf einen Fehler hindeuten (oder unsere Kunden haben uns von einem auf den anderen Tag verlassen…)

Die Ermittlung der KPIs haben wir direkt in der Oracle-Datenbank als View implementiert. Die View stellt die KPIs zur Verfügung, wird vom Applications Manager ausgelesen und über die Ampel visualisiert. Auf diese Weise kann jederzeit ein neuer KPI nur durch Erweiterung der View hinzugefügt werden. Das machen wir insbesondere immer dann, wenn wir mit einem neuen Fehlerfall konfrontiert wurden, den unser Monitoring bisher noch nicht erkannt und visualisiert hat. Somit verbessern wir unser Monitoring stetig.

In der Praxis hat sich dieses Vorgehen bewährt. Es liefert uns neben der technischen System-Überwachung, die unsere Kollegen im Betrieb einsetzen, ein fachliches Monitoring unserer Geschäftsprozesse und erlaubt es uns, Störungen zu erkennen und zu beseitigen, bevor unsere Kunden betroffen sind.

Uwe Khatchikian

techblog@walbusch.de

Kontakt Blog

Wenn Sie Fragen oder Feedback zum Technologie-Blog oder zu einem unserer Beiträge haben, können Sie sich gerne per Mail an unser Technologie-Blog Team wenden!

E-Mail: techblog@walbusch.de