In Computernetzen - sei es nun innerhalb einer Firma oder im Internet - treten ständig Probleme verschiedener Schwere auf. Mal übermittelt ein Router nicht alle Datenpakete, mal ist ein Server überlastet und dadurch nicht erreichbar. Gerade im E-Commerce hängt das Wohl eines Unternehmens jedoch davon ab, dass es seine Dienste rund um die Uhr - also 24 Stunden pro Tag, sieben Tage pro Woche - bereitstellen kann. Die Aufgabe der IT-Abteilung ist es, die Verfügbarkeit der kritischen Ressourcen zu gewährleisten. Festzustellen, wo Systeme nicht mehr volle Leistung bringen oder möglicherweise sogar ausfallen werden, ist dabei fast schon überlebenswichtig. Schließlich kann man nur so sicherstellen, dass man seinen Kunden - externen ebenso wie internen - ein Höchstmaß an Service bieten kann. Genau dafür wurden ursprünglich Alarmfunktionen von Netzkomponenten entwickelt: Sie weisen in Echtzeit auf Probleme hin und bieten so die Möglichkeit, schnell zu reagieren und die Ursache des Übels zu beseitigen.
Prinzipiell lassen sich zwei Methoden unterscheiden, Fehlermeldungen zu generieren: Bei der ersten führen die Netzwerkgeräte eine Selbstdiagnose durch. Sie selbst machen den Administrator auf Fehler aufmerksam und übermitteln die Meldungen in Form von Simple-Network-Management-Protocol-(SNMP-)Traps. Der zweite Ansatz besteht darin, dass man den Status der verschiedenen Geräte im Netzwerk in regelmäßigen Abständen abfragt. Die bei dieser Methode, dem Polling, gesammelten Daten werden untersucht - so lässt sich feststellen, was falsch läuft. "Openview" von Hewlett-Packard (HP) beispielsweise schickt regelmäßig Pings an die einzelnen Geräte, um herauszufinden, ob sie verfügbar sind oder innerhalb festgelegter Schwellenwerte reagieren.
Beide Verfahren haben allerdings einen gravierenden Nachteil: Es werden sehr viele nicht relevante Meldungen übertragen. Dadurch entsteht eine Art Hintergrundrauschen (Noise), das in der Regel stärker ist als die übermittelten Nutzinformationen und diese zu überlagern droht. Das liegt daran, dass die Alarmauslöser sofort auf bestimmte Situationen reagieren und dabei bereits vorhandene Erfahrungswerte nicht berücksichtigen - schließlich soll die Benachrichtigung ja in Echtzeit erfolgen. So meldet zum Beispiel ein Router, dass er überlastet ist und löst so eine Fehlermeldung aus, die den Administrator über eine Steigerung des Traffic informiert. Eine Sekunde später ist der Router aber vielleicht schon nicht mehr überlastet, die Fehlermeldung ist jedoch bereits unterwegs. In manchen Fällen wird die Situation sogar noch unnötig dadurch verschärft, dass der Router dann eine weitere Meldung abschickt - dieses Mal, um Entwarnung zu geben und mitzuteilen, dass er nicht mehr überlastet ist.
Herausforderung für den AdministratorUnabhängig davon, welche der beiden beschriebenen Methoden eingesetzt wird: Die für die IT-Infrastruktur Verantwortlichen stehen vor der Herausforderung, "echte" Fehlermeldungen aus dem Wust an Nachrichten herauszufiltern, um signifikante Probleme lokalisieren und beheben zu können. Aber bei Millionen eingehenden Fehlermeldungen ist diese Aufgabe ohne Automatisierung schlichtweg nicht zu bewältigen. Schlimmstenfalls sind die Betreffenden von der schieren Menge an Meldungen derart überlastet, dass sie gar nicht mehr unterscheiden können, welche wirklich wichtig sind und welche nicht.
Glücklicherweise gibt es Methoden, die Abhilfe schaffen können. Einer der einfachsten Lösungsansätze im Alarm-Management ist die so genannte "De-Duplication", die Hersteller wie MicroMuse, Spectrum und Nervecenter mit ihren Tools anbieten. Dabei geht man davon aus, dass die Schwierigkeiten der IT-Manager zu einem erheblichen Teil auf redundante Fehlermeldungen zurückzuführen sind. So kommt es immer wieder vor, dass ein einzelnes Gerät zum Beispiel 200 Fehlermeldungen ausgelöst hat, die aber alle von ein und demselben Problem verursacht wurden. Die De-Duplication hat deshalb die Aufgabe, die redundanten Meldungen harauszufiltern. Auch wenn sich das simpel anhören mag, ist diese Methode doch recht wirkungsvoll. Die Anzahl der tatsächlich verschickten Fehlermeldungen lässt sich damit von einigen Millionen auf wenige Zehntausend reduzieren.
Wo sitzt der wirkliche Fehler?Einen Schritt weiter geht die "Root Cause Correlation", auf die Firmen wie Smart und Riversoft setzen: Dabei lässt die Management-Software nur solche Fehlermeldungen durch, die durch tatsächliche Ausfälle ausgelöst werden. Das Ziel ist es dabei, eine gestörte Netzkomponente, also die wirkliche Fehlerquelle (Root Cause), gezielt ausfindig zu machen. Fehlermeldungen anderer Geräte, auf die wegen des Ausfalls des Fehlerverursachers zurzeit kein Zugriff möglich ist, werden dabei nicht angezeigt.
"State Machine" von Nervecenter funktioniert nach einem ähnlichen Prinzip, arbeitet allerdings etwas komplexer: Das Tool sucht nicht einfach nur den Fehlerverursacher, sondern lässt sich zusätzlich noch über komplexere Algorithmen steuern. Die Idee dahinter ist, allen Fehlermeldungen nachzugehen, um so nicht nur die Quelle der Fehlermeldungen, sondern das Kernproblem schneller zu finden. Wenn ein Gerät zum Beispiel die Meldungen a, b und c ausgibt, kann State Machine erkennen, dass sich beispielsweise hinter c das tatsächliche Problem verbirgt.
Produkte wie State Machine stellen bereits die Grundlage für weiterreichende anspruchsvolle Lösungen dar. Allerdings erfordern sie, wenn sie effizient eingesetzt werden sollen, zusätzliche Arbeitszeit und Mehraufwand von den ohnehin schon überarbeiteten IT-Mitarbeitern. Gemeinsam ist diesen Tools, dass sie die eingegangenen Fehlermeldungen überprüfen, um festzustellen, was bei dem jeweiligen Netzwerkgerät überhaupt "los" ist. Danach versuchen sie, differenzierte Aussagen über den Status des Geräts zu treffen. Dass sich diese Lösungen bislang nicht auf breiter Linie durchgesetzt haben, liegt vor allem an der sehr komplexen Handhabung.
Leider lässt sich das Problem des Alarm-Managements auch mit den beschriebenen Ansätzen nicht zufriedenstellend lösen: Die IT-Abteilung sieht sich nach wie vor mit wesentlich mehr Fehlermeldungen konfrontiert, als sie abarbeiten kann. Neue, weiterentwickelte Lösungen sorgen jedoch verstärkt für eine "intelligentere" Generierung von Fehlermeldungen, was das Hintergrundrauschen spürbar verringert. Dies lässt sich erreichen, indem historische Daten über die Netzauslastung beziehungsweise den Zustand bestimmter Komponenten berücksichtigt werden. So kann die Relevanz bestimmter Fehlermeldungen besser eingeschätzt werden.
Ein Beispiel: Eine Reihe von Fehlermeldungen rührt daher, dass ein Netzwerkgerät regelmäßig einen bestimmten Schwellenwert überschreitet. Wenn das für dieses Gerät aber typisch ist, dann ist das Übertreten des Schwellenwerts irrelevant. Stattdessen ist es sinnvoller, anhand der charakteristischen Reaktionen des Geräts Situationen festzulegen, in denen eine Meldung ausgelöst werden muss. So könnte man zum Beispiel eine Time-over-Treshold-Regel definieren und dann eine Fehlermeldung ausgeben lassen, wenn das Gerät den Schwellenwert zu lange oder auch zu oft innerhalb eines bestimmten Zeitraums überschreitet. Auf diese Art und Weise lässt sich nicht nur die Anzahl unnötiger Alarmmeldungen verringern - man kann so auch periodisch auftretende Probleme schneller erkennen.
Ein weiterer Lösungsansatz nennt sich "Deviation from Normal" und bezeichnet die Abweichung vom Normalzustand. Dabei identifiziert man ungewöhnliches Verhalten aufgrund der "Persönlichkeit" des Netzwerkgerätes. Ist eine bestimmte Leitung regelmäßig zum Beispiel um 9 Uhr am Morgen zu 80 Prozent ausgelastet, wird nur dann eine Fehlermeldung ausgegeben, sobald eine Abweichung (nach oben oder unten) von diesem Verhalten festgestellt wird. Simplere Verfahren sind nicht in der Lage zu erkennen, dass diese hohe Auslastung ganz normal und kein Grund zur Besorgnis ist. Durch den Deviation-from-Normal-Ansatz lässt sich viel Hintergrundrauschen von vornherein vermeiden, da dabei das Verhalten der Geräte, Systeme und Anwendungen beobachtet, jedoch nur auf Abweichungen reagiert wird.
Falscher Alarm?Durch diesen Ansatz erhält der Administrator eine bessere Kontrolle, da er Veränderungen in beide Richtungen, also sowohl Überlastung als auch mangelnde Auslastung, rasch feststellen kann. Bei einigen der oben erwähnten Methoden würde eine Fehlermeldung ausgelöst, sobald die Auslastung 80 Prozent übersteigt, jedoch nicht, wenn die Auslastung signifikant unter 80 Prozent fällt, was ja auch ein Indikator für Probleme sein könnte. Und genau dies macht die Stärke der Deviation-from-Normal-Methode aus: Sie registriert alle Abweichungen vom durch den Benutzer definierten Soll-Zustand.
Idealerweise gelingt es, das System so zu konfigurieren, dass der Verwalter (fast) nur noch solche Meldungen erhält, die auch tatsächlich gewollt sind. Wenn er nun auf eine ankommende Warnung hin eine bestimmte Aktion auslöst, möchte er natürlich wissen, ob die getroffene Entscheidung richtig war. Einige Alarm-Management-Lösungen erlauben, gezielt die aktuellen Performance-Daten ausgewählter Geräte anzuzeigen (typischerweise in einem eigenen Popup-Fenster) und so festzustellen, ob das Problem auch wirklich behoben ist. Diese Anzeige lässt sich aber auch proaktiv einsetzen, um eine Komponente zu beobachten. Außerdem kann die Anzeige dazu dienen, Grundmuster festzustellen und - sobald man ermittelt hat, was dem normalen Verhalten entspricht - stichprobenartig über den Tag verteilt die Ressourcenauslastung zu überprüfen.
Dieser Life- Trend-Ansatz hilft, ein weit verbreitetes Problem zu lösen, denn oft wissen IT-Techniker nicht genau, welches Verhalten für ihre Systeme normal ist. Sie verfügen somit über eine weitere Möglichkeit, um mit Hilfe von historischen Daten herauszufinden, ob beim momentanen Auslastungsgrad tatsächlich Handlungsbedarf besteht. Eine kontinuierliche Abfrage des Status eines Geräts oder einer Anwendung ist dabei nicht nötig.
Neue Tools wie "Live Health" von Concord Communications integrieren historische Systemdaten und das Echtzeit-Management innerhalb einer einzigen Benutzeroberfläche. Dazu nutzt die Software die Daten, die die Tools "Network Health", "System Health" und "Application Health" liefern. Diese Tools überwachen geschäftskritische Anwendungen.
Produkte wie die genannten helfen IT-Managern, in der schier undurchdringbaren Flut von unqualifizierten Daten, die auf Symptome hinweisen, ohne jedoch die wirkliche Fehlerursache aufzuzeigen, den Durchblick zu bewahren. Sie schaffen damit eine wichtige Voraussetzung für die Erreichung eines für alle Unternehmen wichtigen Zieles: die möglichst ständige Verfügbarkeit aller kritischen Ressourcen.
*Jürgen Magiera ist Application Engineer bei der Concord Communications GmbH in Vaterstetten.