Monitoring ist kein Event Management

in oder mehrere Monitoring Tools sind in fast allen IT-Abteilungen in Verwendung. Traditionell liegt hier der Fokus auf dem frühzeitigen Erkennen von Störungen. Im besten Falle sollen kritische Vorfälle automatisiert erkannt und frühzeitig behoben werden, noch bevor diese von Anwendern wahrgenommen werden. Dafür werden unzählige Informationen automatisiert gesammelt: vom Temperatursensor im Datacenter bis zur Anzahl der Shortdumps im SAP-System, von Füllständen der Festplatten bis zum Verfügbarkeitswert des Mail-Clusters. Jede Statusänderung generiert dabei ein „Event“.

Nur wenige Statusänderungen sollten tatsächlich Incidents triggern und nicht jeder Incident ist kritisch. Trotzdem neigen Administratoren dazu, sich über zu viele Events per Email oder SMS benachrichtigen zu lassen. Sie werden unablässig mit Benachrichtigungen geflutet, während Meetings oder in der Freizeit. Nur die wenigsten sind relevant. In vielen Fällen gehen die Benachrichtigungen über eine Sammelmail sogar an mehrere Mitarbeiter, wobei es unklar bleibt, ob Aktionen eingeleitet werden müssen und wer die Verantwortung dafür übernimmt. Die tatsächlich wichtigen Benachrichtigungen gehen dabei leider oft unter, während „false positives“ unnötigen Aufwand verursachen.

Monitoring als zentrale Komponente eines Event-Managements nach ITIL

Die tatsächliche Herausforderung im Monitoring liegt nicht im Sammeln von Daten. Sie liegt vielmehr in der Filterung und Klassifizierung von Informationen und in ihrer sinnvollen Auswertung und Weiterverarbeitung. Der Prozess Event Management in der ITIL-Beschreibung bezieht sich zwar nicht explizit auf das Monitoring, unterstützt uns aber in der sinnvollen Verwendung von den im Monitoring gewonnenen Daten für weitere ITIL-Prozesse. Ein gutes Verständnis des Event Management-Prozesses hilft den Administratoren, die beschriebene Benachrichtigungsflut einzudämmen und gleichzeitig die Servicequalität zu verbessern.

Zunächst muss der IT-Administrator sich selber in den verfügbaren ITIL-Rollen wiederfinden: ITIL beschreibt weitgehend anerkannte Best Practice-Prozesse im IT Service Management und ist Grundlage für Zertifizierungen wie ISO 20000. Rollen und Verantwortlichkeiten im IT-Betrieb werden klar benannt. Im richtigen Leben allerdings muss der Admin zahlreiche Rollen und Verantwortlichkeiten in ein und derselben Person ausfüllen. (Nehmen Sie eine beliebige Stellenbeschreibung „ IT (System-) Administrator“ und versuchen Sie diese in die entsprechenden ITIL-Rollen zu übersetzen. Das ist keine triviale Aufgabe!) Insgesamt gibt es weit über 30 Rollen.

In IT-Abteilungen mit mehreren hundert Mitarbeitern kann es möglich sein, eine dedizierte ITIL-Rolle einem einzigen Mitarbeiter zuzuordnen. Je kleiner die Mitarbeiterzahl einer sich an ITIL orientierenden Abteilung ist, umso mehr Rollen und Verantwortlichkeiten muss ein einzelner Mitarbeiter jedoch ausfüllen. Und genau hier liegt vermutlich die Ursache für die eingangs beschriebene Flut an Benachrichtigungen, die dem Administrator die Mailbox füllen: Er ist oft gleichzeitig Incident Manager, Problem Manager, er ist verantwortlich für Serviceverbesserungen, Emergency Changes, ist Prozessarchitekt und Projektmanager. Für die jeweiligen Rollen sind die im Monitoring generierten Informationen möglicherweise relevant. Unstrukturiert und nicht nach den relevanten Rollen und Prozessen organisiert, sind die Benachrichtigungen aber kontraproduktiv. Deshalb ist es wichtig zu verstehen, wie die Events gefiltert, korreliert und zur Unterstützung weiterer Prozesse aufbereitet werden. Ein gut implementiertes Event Management aggregiert Monitoring-Daten für die Verwendung in weiteren Prozessen und limitiert die Versendung von Alerts auf das Notwendigste.

Event Management nach ITIL gibt der Datenflut Struktur

Monitoring ist also kein eigenständiger Prozess, sondern unterstützt insbesondere den Prozess Event Management. In der ITIL gibt es keine dedizierte Rolle eines „Event Managers“, vielmehr ist das Event Management Bestandteil des Servicebetriebs und wird verantwortet vom IT Operations Manager. Das Monitoring unterstützt IT Operations im Erkennen, Bewerten und Verarbeiten von Events.

Was aber genau ist ein Event nach ITIL? Laut Definition ist ein Event eine für das IT Service Management relevante Statusänderung an einem CI oder einem Service. Das Erkennen dieser Statusänderung übernimmt üblicherweise das Monitoring. Auch eine erste Filterung nach Relevanz wird technisch vom Monitoring vorgenommen, z.B. über konfigurierbare Schwellwerte. Auch wenn keine Ausnahme oder Störung vorliegt, soll das Event zumindest als Information registriert werden: Um historische Daten zu aggregieren, Verfügbarkeiten nachzuweisen („Availability Report“) und um Tendenzen zu erkennen. Diese erste Unterscheidung zwischen reiner Information und Warnung/Ausnahme zur weiteren Bearbeitung nennt sich nach ITIL „Event-Filterung und 1st Level-Korrelation“ und ist in den meisten Monitoring Tools konfigurierbar.

„False positives“ mit der Event-Korrelation begegnen

Als nächsten Schritt sieht ITIL 2nd Level-Korrelation vor. Nur wenige Monitoring-Lösungen ermöglichen eine weitere Bewertung von Warnungen und Ausnahmen. Beispielsweise kann die Störung eines Mailservers gemeldet werden. Da dieser Server aber nur als einer von drei Nodes in einem Mail-Cluster eingebunden ist, bleibt der tatsächliche Mail-Service ungestört. Der Administrator sollte somit nicht akut per SMS oder Mail benachrichtigt werden. Es ist ausreichend, wenn er bei nächster Gelegenheit eine Warnmeldung im Dashboard sieht und die nötigen Schritte einleitet.

Eine weitere Komponente in der Korrelation ist der zeitliche Aspekt: Fällt während der täglichen Arbeitszeiten ein Service aus, sollte ein Incident generiert werden, da die Produktivität der Mitarbeiter eingeschränkt wird. Wenn der gleiche Ausfall außerhalb der Geschäftszeiten erkannt wird, ist es hingegen nicht zwingend notwending, einen Incident zu erstellen.

Konzepte zum Umgang mit Events werden üblicherweise im Servicedesign erarbeitet. Das Monitoring-Tool unterstützt dann bei einer weitestgehend automatisierten Umsetzung dieser Konzepte. Eine 1st-Level Korrelation findet bereits über die erwähnte Einstellung von Schwellwerten statt, die auch im laufenden Betrieb konstant überprüft und angepasst werden sollten. In der 2nd-Level Korrelation greifen dann anspruchsvollere Mechanismen: Die Events sollen über eine konfigurierbare Logik interpretiert und eingeordnet werden. Notwendige Reaktionen sollen dabei eingeleitet werden und unnötige Benachrichtigungen sollen vermieden werden.

Fazit

Ein Monitoring-System, das konstant Benachrichtigungen über Statuswechsel versendet, ist kontraproduktiv: Erfahrungsgemäß gehen dort relevante Meldungen unter, landen im Spamordner der Admins und erhöhen somit die Ausfallrisiken. Ein Tool, das eine automatisierte Event-Korrelation unterstützt, ermöglicht die Reduktion der Benachrichtigungen auf relevante Incidents, die an einen Helpdesk zur weiteren Bearbeitung übergeben werden. Hier findet dann die tatsächliche Aufgabenverteilung statt: Es werden Verantwortlichkeiten und Reaktionszeiten festgelegt und deren Einhaltung überprüft. Die Reduktion der Meldungen auf tatsächliche Incidents erlaubt den fachlich Zuständigen angemessene Maßnahmen einzuleiten. Sie sind nicht mehr damit befasst, unzählige Statusmeldungen manuell zu überprüfen.

Ein gut konzipiertes Event Management nutzt das Monitoring weiterhin, um umfassende Informationen zu Statusänderungen zu sammeln und für weitere Analysen zur Verfügung zu stellen. Eine Event Korrelation erweitert aber darüber hinaus das Monitoring um eine automatisierte Filterung und Bewertung der generierten Daten im Hinblick auf gefährdete Services. Erst wenn Handlungsbedarf erkannt wird, erstellt das Monitoring dann einen Incident. „False positives“ werden damit reduziert oder gar eliminiert. Die Bewertung und Auslese von Incidents ermöglicht es Administratoren also, ihre Arbeitszeit für die wirklich wichtigen Problemen einzusetzen, und befreit sie von der täglichen Datenflut.