Überblick statt Überlastung So bekommen IT-Teams unzählige Alerts unter Kontrolle

Ein Gastbeitrag von Stefan Marx 5 min Lesedauer

Anbieter zum Thema

Der Begriff Tech-Stack macht deutlich: IT-Teams befassen sich heute mit einem ganzen Stapel an Software. Aus dieser Komplexität folgen viele Herausforderungen und Fehlfunktionen, auf die automatisierte Benachrichtigungen hinweisen können. Doch auch deren Menge nimmt immer weiter zu. Gehen die Teams in der schieren Menge der Meldungen unter und verlieren den Überblick, spricht man von „Alert Fatigue“.

Durch die wachsende Komplexität von Tech-Stacks und deren laufende Veränderung wird es für  IT-Teams immer schwerer, den Überblick zu behalten, denn zu viele Alerts trüben den Fokus. Daher ist es wichtig, sowohl die Software selbst zu überwachen und anzupassen als auch deren Monitoring.(Bild:  lucadp - stock.adobe.com)
Durch die wachsende Komplexität von Tech-Stacks und deren laufende Veränderung wird es für IT-Teams immer schwerer, den Überblick zu behalten, denn zu viele Alerts trüben den Fokus. Daher ist es wichtig, sowohl die Software selbst zu überwachen und anzupassen als auch deren Monitoring.
(Bild: lucadp - stock.adobe.com)

Warnmeldungen müssen regelmäßig mit dem Tech-Stack aktualisiert werden. Passiert das nicht, kann das zu irrelevanten oder sogar falsch-positiven Benachrichtigungen führen. Sind IT-Teams ob der schieren Menge überfordert und können relevante Meldungen nicht mehr herausfiltern, spricht man von Alert Fatigue. Das ist einerseits frustrierend für die Mitarbeiter und andererseits kann es dem Unternehmen schaden: So entstehen ineffiziente Prozesse und wichtige Sicherheitslücken bleiben unerkannt – was Cyberangriffe erleichtert. Doch Unternehmen können etwas dagegen unternehmen und im Tech-Stack für System Health und bei Angestellten für Mental Health sorgen.

Um Alert Fatigue vorzubeugen ist es wichtig, die Monitoring-Strategie kontinuierlich zu überprüfen und zu aktualisieren. Unnötige Benachrichtigungen sollten in diesem Zuge entfernt oder an die neuen Gegebenheiten angepasst werden. In größeren Unternehmen mit Tausenden von Warnungen erfolgt die Umsetzung am besten auf Teamebene. So können die Unternehmen sicherstellen, dass die Benachrichtigungen zu den spezifischen Aufgaben der einzelnen Teams passen.

Wo drückt der Schuh?

Zunächst müssen dafür die störenden Alerts identifiziert werden. Das sind oft genau diejenigen, die am häufigsten ausgelöst werden. Im Großen und Ganzen kann man hier zwischen zwei Arten von Alerts unterscheiden: vorhersehbare und instabile .

  • Vorhersehbare Alerts: Einige Meldungen bilden konstante und somit vorhersehbare Muster. Das sind zum Beispiel Benachrichtigungen zum Start und Ende eines automatisierten Back-ups. Auch Warnungen für Probleme, die zwar unerwünscht sind, aber regelmäßig auftreten und akut keine Gefahr darstellen, gehören dazu. Ein Alarm sollte allerdings nur ausgelöst werden, wenn ein unerwartetes Ereignis eintritt. Für die Back-up-Meldungen bedeutet das: Sollte dabei etwas nicht funktionieren, geht der entsprechende Alert unter Umständen zwischen den regulären Statusmeldungen unter.
  • Instabile Alerts:Solche Alerts informieren in unnötig hoher Frequenz darüber, dass etwas zwischen verschiedenen Zuständen hin- und herwechselt. Meist muss auf diese Alerts erst gar nicht reagiert werden, weil sie sich von selbst wieder lösen oder nur kurzzeitige Lastspitzen darstellen. Auch hier bietet sich das Back-up-Beispiel an: Eine Warnung wird z. B. ausgelöst, wenn die Festplattennutzung länger als fünf Minuten 90 Prozent überschreitet. Sobald die Sicherung abgeschlossen ist und die Festplattenauslastung unter 90 Prozent sinkt, wird der Status der Warnung wieder auf OK gesetzt. Solche Warnmeldungen können die Teams schnell überfordern, denn auch diese Alerts benachrichtigen nicht über irreguläre Vorgänge und erzeugen so Rauschen in den Daten.

Weniger ist mehr

Sobald die störenden Benachrichtigungen identifiziert sind, können sie angepasst werden, um die Warnfrequenz zu verringern und ihre Wirksamkeit zu erhöhen. Dazu kann es helfen, das Auswertungsfenster auszuweiten. Das Auswertungsfenster definiert die Häufigkeit, mit der das Überwachungstool die relevanten Daten auswertet und mit den Warnbedingungen vergleicht. Ein weit verbreiteter Irrglaube ist, dass ein größeres Auswertungsfenster langsamere Reaktionen oder verpasste Alarme verursachen könnte, aber das ist nicht der Fall. Die Software wertet die zugrundeliegenden Daten kontinuierlich aus. Eine Vergrößerung des Auswertungsfensters gewährleistet, dass das System vor einer Entscheidung mehr Datenpunkte berücksichtigt. So wird ausschließlich gewarnt, wenn eine Grenzüberschreitung dauerhaft auftritt.

Ein ähnliches Vorgehen bietet sich bei instabilen Alerts an. Für solche lassen sich Schwellenwerte für die Wiederherstellung definieren. Das IT-Team erhält dadurch erst eine Benachrichtigung, wenn ein Schwellenwert über eine längere Zeit überschritten wird. Ist die Bedingung für einen Alert beispielsweise, dass die CPU-Auslastung eines Servers 80 Prozent überschreitet, wirkt in diesem Falle eine automatische Skalierung bei einmaligen Spitzen dagegen. Binnen kurzer Zeit ist die Auslastung wieder unter dem Schwellenwert, sodass der Status automatisch umspringt und ein manuelles Eingreifen sich erübrigt.

Alerts konsolidieren

IT-Teams können Alerts auch in bestimmten Gruppen organisieren, z. B. nach Service, Cluster, Host, Gerät und weiteren Kriterien. Um Alert Fatigue vorzubeugen, sollten sie darauf achten, eine Entität nicht in mehrere Gruppen gleichzeitig zu stecken. Sonst können durch die große Anzahl von beobachteten Entitäten Alarme schnell unübersichtlich werden. Nehmen wir einmal an, die Latenz einer Gruppe kritischer Dienste, die jeweils auf mehreren Hosts laufen, soll überwacht werden. Man definiert daher einen Alert mit zwei Dimensionen: Host und Service. Wann immer nun ein einzelner Host nicht verfügbar ist, folgen Benachrichtigungen über den Zustand sowohl des Hosts als auch des Services. Letztere sind dann aber irrelevant. Bündelt man den Alert allerdings für die Service-Dimension, senkt das die Anzahl der Benachrichtigungen. Gleichzeitig ist nach wie vor möglich, Informationen auf Service- und Host-Level zu erhalten – das Rauschen aber auf ein Minimum zu reduzieren.

Außerdem hilft es, die Empfänger der Alerts einzuschränken, sodass nur diejenigen die Benachrichtigungen erhalten, die sich auch darum kümmern können. Und umgekehrt: Die Meldung geht nur an die Teams, die sie auch betreffen. Darüber hinaus ist es mit einigen Plattformen möglich, Alerts direkt nach Priorität zu ordnen. Bei Wartungsarbeiten oder Upgrades ist es sinnvoll, Benachrichtigungen komplett auszusetzen. Während einer bewussten Downtime warnt das Monitoring dann nicht fortlaufend vor Unregelmäßigkeiten, was dem IT-Team eine Nachrichtenflut erspart.

Wissen, was läuft

Täglich die wichtigsten Infos aus dem ITK-Markt

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Den Durchblick behalten

Gerade im Zuge der Digitalisierung mit wachsender Komplexität von Tech-Stacks und ihrer laufenden Veränderung müssen IT-Teams und Unternehmen den Überblick behalten. Zu viele Alerts trüben aber den Fokus. Daher ist es wichtig, sowohl die Software selbst zu überwachen und anzupassen als auch deren Monitoring. Das betrifft zum einen die entsprechende Sensibilisierung der Teams, zum anderen bieten auch entsprechende Plattformen die Möglichkeit, Alerts zu organisieren. Das erleichtert nicht nur die Arbeit der IT-Teams, sondern ermöglicht effizientere und damit wirtschaftlichere Prozesse im Unternehmen.

Über den Autor: Stefan Marx ist Director Platform Strategy beim Cloud-Monitoring-Anbieter Datadog. Marx ist seit über 20 Jahren in der IT-Entwicklung und -Beratung tätig. In den vergangenen Jahren arbeitete er mit verschiedenen Architekturen und Techniken wie Java Enterprise Systemen und spezialisierten Webanwendungen. Seine Tätigkeitsschwerpunkte liegen in der Planung, dem Aufbau und dem Betrieb der Anwendungen mit Blick auf die Anforderungen und Problemstellungen hinter den konkreten IT-Projekten.

(ID:50120887)