Monitoring ist kein Event-Management

Wider die Datenflut

20. September 2018, 7:00 Uhr | Dirk Seiffert

Nicht jedes Event ist ein Incident, und Monitoring ist kein Event-Management. Diese einfache Tatsache vergessen viele Administratoren. Der Unterschied ist aber wichtig, denn es geht darum, das Monitoring in Bezug auf ein nach ITIL ausgerichtetes IT-Service-Management zu verbessern.

In den meisten IT-Abteilungen kommen ein oder mehrere Monitoring-Lösungen zum Einsatz - im Normalfall, um Störungen frühzeitig erkennen zu können. Ziel des Monitorings ist es, kritische Vorfälle automatisiert zu erkennen und rechtzeitig zu beheben, sodass der Anwender im Idealfall davon nichts mitbekommt. Zu diesem Zweck sammeln die unterschiedlichen Tools eine Flut an Informationen: 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. Dabei erzeugt jede Statusänderung ein "Event".

Zwar ist nicht jeder Incident (Zwischenfall) kritisch, und nur wenige Statusänderungen sollten tatsächlich Incidents triggern. Dennoch lassen sich viele Administratoren über zu viele Events per E-Mail oder SMS benachrichtigen. Egal, ob zu Hause oder während Meetings, sie werden ständig mit Alerts geflutet. Dabei ist nur ein kleiner Teil davon wichtig. Häufig gehen die Benachrichtigungen sogar an mehrere Mitarbeiter gleichzeitig, wobei nicht klar ist, ob eine Reaktion nötig ist und wer letztendlich verantwortlich dafür ist. Die wirklich wichtigen Störungen gehen dadurch unter, während falsche Benachrichtigungen unnötigen Aufwand verursachen.

Monitoring als zentraler Baustein

Tatsächlich liegt die wirkliche Herausforderung im Monitoring nicht im Sammeln von Informationen. Es geht um die Filterung und Klassifizierung von Daten und ihre sinnvolle Auswertung und Weiterverarbeitung. Auch wenn sich in ITIL der Prozess Event-Management nicht explizit auf die IT-Überwachung bezieht, unterstützt er die IT bei dem sinnvollen Einsatz der im Monitoring gewonnenen Daten für weitere ITIL-Prozesse. Administratoren, die den Event-Management-Prozess richtig verstanden haben, tun sich leichter, die beschriebene Alarmflut einzudämmen und gleichzeitig die Service-Qualität zu optimieren.

Der IT-Administrator besitzt laut ITIL klar umrissene Zuständigkeiten. Im IT-Alltag muss er allerdings zahlreiche Rollen und Verantwortlichkeiten in ein und derselben Person ausfüllen.

Man versuche einmal, eine Stellenbeschreibung für einen IT-Administrator in die entsprechenden ITIL-Rollen zu übersetzen: Dies ist keine triviale Aufgabe, da es insgesamt weit über 30 Rollen gibt.

Eine IT-Abteilung, die über mehrere hundert Mitarbeiter verfügt, kann sicher einem einzelnen Mitarbeiter eine dedizierte ITIL-Rolle zuordnen. Der Normalfall dürfte jedoch eher sein, dass ein Mitarbeiter mehrere Rollen und Verantwortlichkeiten einnehmen muss. Und genau das ist der Grund für die beschriebene Datenwelle: Der Administrator ist gleichzei-tig Incident-Manager, Problem-Manager, er verantwortet Service-Verbesserungen, Emergency Changes und ist Prozessarchitekt und Projekt-Manager. Die Daten aus dem Monitoring sind für diese Rollen möglicherweise relevant. So lange sie unstrukturiert vorliegen und nicht nach den jeweiligen Rollen und Prozessen organisiert sind, sind sie aber kontraproduktiv. Es muss daher klar zu verstehen sein, wie die Events gefiltert, korreliert und zur Unterstützung weiterer Prozesse aufbereitet werden. Ein gutes Event-Management fasst Informationen für den Einsatz in weiteren Prozessen zusammen und beschränkt die Versendung von Benachrichtigungen auf das Notwendigste.

Event-Management nach ITIL

Bei der IT-Überwachung handelt es sich also nicht um einen eigenständigen Prozess, sondern sie unterstützt vor allem den Prozess Event-Management. ITIL sieht keine eigene Rolle für einen "Event-Manager" vor, sondern betrachtet das Event-Management als Teil des Service-Betriebs, für den der IT-Operations-Manager verantwortlich ist. Durch das Erkennen, Bewerten und Verarbeiten von Events unterstützt das Monitoring den IT-Betrieb.

Was aber genau ist ein Event nach ITIL? Eine für das IT-Service-Management relevante Statusänderung an einem CI oder einem Service. Üblicherweise liegt das Erkennen dieser Statusänderung beim Monitoring, genauso wie eine erste Filterung nach Wichtigkeit, etwa über konfigurierbare Schwellenwerte. Das Event soll als Information erfasst werden, auch wenn keine Ausnahme oder Störung vorliegt, um historische Daten zu aggregieren, Verfügbarkeiten nachzuweisen und Tendenzen zu erkennen. ITIL nennt diesen ersten Schritt, der eine Trennung von der reinen Information und der Klassifizierung als Warnung oder Ausnahme umfasst, "Event-Filterung und First-Level-Korrelation". In den meisten Monitoring-Lösungen lässt sich dieser Schritt konfigurieren.

Mit Event-Korrelation gegen "False Positives"

Der nächste Schritt umfasst laut ITIL die Second-Level-Korrelation, das heißt, eine weitere Bewertung von Warnungen und Ausnahmen. Das ist nur in wenigen Tools vorgesehen. Bei der Störung eines Mail-Servers ist es beispielsweise nicht nötig, eine Störung zu melden, wenn dieser nur als einer von drei Nodes in einen Mail-Cluster eingebunden ist und der tatsächliche Mail-Service ungestört bleibt. In so einem Fall muss das System den Administrator nicht akut per SMS oder E-Mail informieren. Es reicht, wenn er beim nächsten Blick ins Monitoring den Alert sieht und dann die erforderlichen Maßnahmen ergreift.

LL09F04_Bild2
Tatsächlich liegt die wirkliche Herausforderung im Monitoring in der Filterung und Klassifizierung von Daten und ihrer sinnvollen Auswertung und Weiterverarbeitung. Bild: IT-Novum

Second-Level-Korrelation befasst sich also weniger mit dem Setzen von Schwellenwerten, als vielmehr mit deren Bewertungen hinsichtlich der Abhängigkeiten unterschiedlicher Services und der Auswirkungen möglicher Störungen auf den Unternehmensbetrieb. Wenn beispielsweise der Lagerist keinen Lieferschein ausdrucken und somit ein LKW nicht termingerecht das Warenlager verlassen kann, entsteht ein erheblicher finanzieller Schaden. Um einem solchen Ausfall vorzubeugen, reicht es nicht, einzelne Services mit Schwellenwerten zu versehen. Die relevanten Services und Sub-Services sollte man auch über eine Event-Korrelation in Abhängigkeit zueinander setzen: Zunächst einmal müssen SAP-Basis, Applikation, Hardware, Datenbank und Betriebssystem überwacht werden. Die Erreichbarkeit der Applikation vom Standort des Anwenders wird per End-to-End-Monitoring überprüft. Auch Toner- und Papierstände der lokalen Drucker gilt es zu überwachen und zu korrelieren. Geht bei Drucker A der Toner zuneige, wird für den Service "SAP Logistics" eine Warnung angezeigt. Hat dann Drucker B einen Papierstau, setzt sich der gesamte Service auf "Critical". Korrelationen können wiederum Bestandteil weiterer Korrelationen sein.

Aufgrund der Komplexität dieser Abhängigkeiten ist es hilfreich, entsprechende Service-Strukturen visuell darzustellen. Tools wie beispielsweise openITCockpit bieten eine entsprechende grafische Oberfläche, um Event-Korrelationen zu entwerfen - und dann im Betrieb auch auf einen Blick die Ursache einer Störung innerhalb eines Service-Baums nachvollziehen zu können.

Der zeitliche Aspekt gehört ebenfalls zur Korrelation: Das System sollte einen Incident generieren, wenn während der Geschäftszeiten ein Service ausfällt, weil dadurch die Produktivität des Unternehmens betroffen ist. Passiert der gleiche Ausfall außerhalb der Arbeitszeit, ist es hingegen nicht zwingend notwendig, dass es einen Incident erzeugt.

Normalerweise erstellt man die Konzepte zum Umgang mit Events im Service-Design. Das Monitoring-Tool kommt dazu, wenn es an die automatisierte Umsetzung der Konzepte geht. Eine First-Level-Korrelation passiert über die erwähnte Einstellung von Schwellenwerten, die man auch im laufenden Betrieb kontinuierlich überprüfen und anpassen sollte. Bei der Second-Level-Korrelation kommen ausgefeiltere Mechanismen zum Einsatz, die die Events über eine konfigurierbare Logik interpretieren und einordnen. Ziel ist es, die richtigen Reaktionen zu initiieren und zudem unnötige Benachrichtigungen zu vermeiden.

Dirk Seiffert ist Account Manager bei IT-Novum, www.it-novum.com.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Toshiba Mobile Communications Division

Matchmaker+