30.000 Alarme und die KI

Neulich in einem Fachmagazin: “Montag morgen und es liegen wieder 30.000 Alarme aus dem Monitoring-System im Postfach – wie KI Ihnen hier helfen kann.” Eine ganze Branche scheint sich darauf eingeschossen zu haben, dass irgendeine Form von Künstlicher Intelligenz das Problem schon lösen wird. Ich glaube: Das ist die falsche Frage – oder zumindest die zweite Frage in der falschen Reihenfolge.

Die 30.000 sind sicher als Eye-Catcher gewählt – eine plakative Zahl, die ins Auge springt und Aufmerksamkeit erzeugt. Das funktioniert, und ich verstehe, warum Redaktionen so schreiben. Aber: Der Punkt, den ich hier mache, gilt schon bei 1.000 Alarmen. Oder bei 300. Sobald ein Postfach täglich mit Alarmen geflutet wird, die niemand mehr ernsthaft liest, ist das Problem da – unabhängig von der konkreten Zahl.

Denn wer am Montag mit einer solchen Alarmflut konfrontiert ist, hat kein KI-Problem. Er hat ein Monitoring-Problem. Und keine noch so kluge Korrelations-Engine wird daran etwas ändern, solange die Ursache nicht angefasst wird. KI hilft nicht beim Aufräumen schlechter Konfiguration – sie verschleiert sie höchstens eleganter.

Drei Ursachen, eine ehrliche Diagnose #

Wenn ein Postfach Montag früh überquillt, gibt es im Wesentlichen drei mögliche Erklärungen. Keine davon hat mit fehlender KI zu tun.

Erstens: Die Infrastruktur ist tatsächlich kaputt. Das ist der seltenste Fall, aber der einzige, in dem die Alarme ihren Job machen. 30.000 Meldungen über ein Wochenende bedeuten dann, dass etwas Substanzielles ausgefallen ist – ein Storage-Backend, ein zentraler Switch, ein Cluster-Knoten – und die nachgelagerten Checks zu Recht Feuer schreien. Hier hilft kein Filter und keine Zusammenfassung. Hier hilft nur: hinfahren, reparieren, aufräumen.

Zweitens: Die Infrastruktur ist zu groß für eine einzelne Person. Wer allein für ein Setup verantwortlich ist, das im Normalbetrieb mehrere tausend Alarme pro Tag produziert, hat ein organisatorisches Problem, kein technisches. Solche Umgebungen brauchen Teams mit klaren Zuständigkeiten, Schichtmodellen und einem Eskalationspfad, der nicht in einem persönlichen Postfach endet. Eine KI, die das Postfach vorsortiert, ändert nichts an der unterliegenden Personalfrage – sie verschiebt sie nur, bis das nächste Loch aufreißt.

Drittens – und das ist der wahrscheinlichste Fall: Die Thresholds sind falsch eingestellt. Irgendwann wurde ein Standard-Alert ausgerollt, nie nachjustiert, und jetzt feuert er bei jeder normalen Last- oder Speicherspitze. Oder es wurden über Jahre Alerts hinzugefügt, ohne je welche zu entfernen. Oder Alerts wurden auf Symptomen statt auf Ursachen definiert, sodass ein einzelnes Ereignis zwanzig Folge-Alarme auslöst. Das Postfach ist dann nur das Symptom – die Krankheit liegt in der Konfiguration.

Symptome lauter machen löst keine Ursachen #

Genau hier wird der KI-Pitch verführerisch. “Lass die KI die 30.000 Alarme zusammenfassen, dedupliziieren, priorisieren – dann musst du nur noch die wichtigen drei lesen.” Klingt pragmatisch. Ist aber das Gegenteil von guter Administration.

Denn was passiert tatsächlich? Die KI lernt, das Rauschen zu glätten. Damit verschwinden nicht nur die Fehlalarme aus dem Sichtfeld, sondern auch die Hinweise, dass das Monitoring überhaupt überarbeitet gehört. Die eigentliche Arbeit – Thresholds prüfen, Alerts konsolidieren, Routing aufräumen – wird unsichtbar gemacht statt erledigt. Und wenn dann irgendwann ein echter Vorfall in einem Muster auftritt, das die KI als “üblich” gelernt hat, geht er unter.

Gutes Alerting ist ein Designproblem, kein Volumenproblem. Die richtige Frage ist nicht “Wie filtere ich 30.000 Alarme?”, sondern “Warum sind es überhaupt 30.000?”

Was stattdessen hilft: Alert-Hygiene #

Bevor man über KI nachdenkt, lohnt sich eine Runde durch die eigene Alert-Konfiguration. Ein paar Prinzipien, die sich in der Praxis bewähren – auch in kleineren Umgebungen, wie ich sie für meine Kunden und in meinem eigenen Cluster betreibe:

Alarmiere auf Symptome, die Menschen interessieren, nicht auf Metriken, die Maschinen produzieren. Eine CPU-Auslastung von 95 % ist keine Information – die Frage ist, ob ein Service deshalb seine SLOs verletzt. Wer auf User-facing-Symptome alarmiert (Antwortzeiten, Fehlerraten, Verfügbarkeit) statt auf Ressourcen-Metriken, reduziert das Volumen oft um eine Größenordnung.

Setze Schwellwerte auf Basis tatsächlicher Daten, nicht auf Bauchgefühl. Was ist die normale Last am Dienstagvormittag? Wie sieht ein typischer Backup-Lauf in der Nacht aus? Ohne diese Baseline ist jeder Threshold geraten – und wenn er geraten ist, wird er zu eng oder zu weit gesetzt. Ein paar Wochen Daten ansehen kostet weniger Zeit als ein Jahr Fehlalarme.

Konsolidiere abhängige Alerts. Wenn ein Knoten ausfällt, müssen nicht zwanzig darauf laufende Pods, ihre Volumes, ihre Ingress-Routen und ihre nachgelagerten Health-Checks einzeln alarmieren. Prometheus’ inhibit_rules im Alertmanager sind genau dafür gedacht – ein Alert auf der Wurzel-Ursache, der die Folge-Alerts unterdrückt. Das ist keine fünfminütige Konfiguration, aber sie spart pro Vorfall hunderte Mails.

Trenne Alarmkanäle nach Dringlichkeit. Was um drei Uhr nachts jemanden wecken muss, gehört nicht in denselben Kanal wie der wöchentliche Zertifikats-Reminder. Bei mir landen kritische Alarme über Alertmanager direkt als Push-Notification, alles andere geht in einen separaten Kanal, der morgens beim Kaffee gesichtet wird. Gatus übernimmt die externen Endpoint-Checks und alarmiert nur, wenn ein Service tatsächlich von außen nicht erreichbar ist – nicht bei jeder internen Schluckaufmeldung.

Räume regelmäßig auf. Ein Alert, der lange nicht gefeuert hat, ist nicht automatisch schlecht – manche Alerts sollen genau das tun: monatelang still bleiben und nur dann anschlagen, wenn wirklich etwas passiert. Aber jeder dieser Alerts gehört regelmäßig auf den Prüfstand: Feuert er noch korrekt, wenn die Bedingung eintritt? Passt der Schwellwert noch zur aktuellen Last? Existiert der überwachte Service überhaupt noch in der gewünschten Form? Manche überleben das Review, andere fliegen raus. Beides ist ein gutes Ergebnis. Alert-Hygiene ist Wartungsarbeit, kein einmaliges Setup.

Wo KI tatsächlich hilft #

Damit kein falscher Eindruck entsteht: KI ist ein hervorragendes Werkzeug, und ich nutze sie täglich. Aber sie ist eben das – ein Werkzeug. Sinnvoll wird sie im IT-Betrieb dort, wo sie aufgeräumte Daten verarbeitet:

Bei der Anomalie-Erkennung in sauber instrumentierten Systemen kann ML-basiertes Alerting Muster finden, die statische Thresholds nicht erfassen – beispielsweise saisonale Veränderungen oder schleichende Performance-Drifts. Das setzt aber voraus, dass die Daten überhaupt belastbar sind.

Bei der Korrelation über mehrere Datenquellen – Logs, Metriken, Traces – kann KI Zusammenhänge sichtbar machen, die ein Mensch im Eifer eines Vorfalls übersieht. Auch hier gilt: Müll rein, Müll raus. Eine Korrelation über schlecht strukturierte Logs liefert schlecht strukturierte Hypothesen.

Beim Sichten und Auswerten großer Logmengen spielt KI eine ihrer größten Stärken aus. Wer schon einmal mehrere Gigabyte Loki-Output nach einem Vorfall durchsucht hat, weiß, wie zermürbend das ist. Ein LLM kann hier in Minuten erledigen, wofür ein Mensch Stunden braucht: relevante Stack-Traces herausfiltern, ungewöhnliche Muster markieren, einen Zeitstrahl der Ereignisse zusammenstellen. Das ersetzt nicht die Bewertung – die bleibt beim Administrator – aber es verkürzt den Weg zur eigentlichen Erkenntnis dramatisch. Genau hier wird KI zum echten Produktivitätshebel im Tagesgeschäft.

Beim Schreiben und Verstehen von Konfiguration – PromQL-Queries, Alertmanager-Routen, Runbooks – ist ein LLM ein produktiver Sparringspartner. Hier ersetzt es nicht das Denken, sondern beschleunigt die Umsetzung dessen, was man durchdacht hat.

Der gemeinsame Nenner: KI hilft, wenn die Hausaufgaben gemacht sind. Sie ersetzt die Hausaufgaben nicht.

Fazit #

Eine Infrastruktur sauber am Laufen zu halten, ist kein Volumenproblem, sondern ein Denkproblem. Die Frage ist nicht, wie viele Alarme man verarbeitet, sondern welche man überhaupt erzeugt – und warum. Wer das ernst nimmt, kommt mit deutlich weniger als 30.000 Mails am Montag aus, ganz ohne KI im Postfach.

Und wer dann zusätzlich KI einsetzt – für Anomalieerkennung, Korrelation, schnellere Konfiguration – holt einen echten Hebel heraus. Aber eben als Verstärker guter Administration, nicht als Ersatz für sie.

Die ehrliche Botschaft an alle, die mit dem 30.000-Alarme-Aufhänger geworben werden: Bevor Sie über KI nachdenken, denken Sie über Ihr Monitoring nach. Es ist die unbequemere, aber günstigere Antwort.

Diskutieren Sie mit: Dieser Artikel ist auch auf LinkedIn erschienen. Ich freue mich über Ihre Vernetzung und einen Austausch zum digitalen Standort Kiel!