On-Call-Teams kennen das Problem: Das Monitoring schlägt an, die Benachrichtigung kommt um drei Uhr nachts, und nach dem Einwählen stellt sich heraus, dass es sich um denselben bekannten False Positive handelt wie die Woche zuvor. Alert Fatigue gehört zu den größten operativen Belastungen in der modernen IT – und klassische Schwellenwert-Konfigurationen lösen das Problem nicht dauerhaft. Genau hier setzen KI-gestützte Alerting-Ansätze an, die 2026 zunehmend produktionsreif sind.
Das eigentliche Problem: Zu viele Alarme, zu wenig Signal
Monitoring-Systeme sind in den letzten Jahren enorm leistungsfähiger geworden. Mit Tools wie Prometheus, Grafana, Datadog oder OpenTelemetry lassen sich heute Tausende von Metriken erfassen und auswerten. Das Problem: Mit der Datenmenge wächst auch die Alarmflut. Viele Teams kämpfen täglich mit Hunderten von Benachrichtigungen, von denen ein großer Teil entweder False Positives sind, bereits bekannte Zustände beschreiben oder sich auf Probleme beziehen, die sich von selbst auflösen.
Die Folge ist ein klassisches Signal-Rausch-Problem. Teams verlieren zunehmend das Vertrauen in ihre eigenen Monitoring-Systeme und beginnen, Alarme systematisch zu ignorieren – was genau das Gegenteil des ursprünglichen Zwecks ist. Wer zu oft für Nicht-Ereignisse geweckt wird, reagiert irgendwann auch auf echte Vorfälle langsamer und weniger konzentriert.
Wie KI beim Alerting grundsätzlich ansetzt
Künstliche Intelligenz kann in diesem Kontext auf mehreren Ebenen helfen. Statt Alarme nach starren Schwellenwerten auszulösen, lernen ML-Modelle die typischen Verhaltensmuster eines Systems – über Tages-, Wochen- und Saisonzyklen hinweg. Ein Anstieg der CPU-Last um 30 Prozent ist in einem Batch-Verarbeitungsfenster nachts vollkommen normal; derselbe Anstieg an einem Sonntagvormittag ohne geplante Jobs dagegen nicht. Diese Kontextabhängigkeit ist für regelbasierte Systeme schwer abzubilden, für trainierte Modelle jedoch relativ direkt zugänglich.
Drei Bereiche stehen dabei im Vordergrund:
- Dynamische Schwellenwerte: Statt fixer Grenzwerte passen sich Schwellenwerte automatisch an historische Muster an und berücksichtigen Tageszeiten, Wochentage und bekannte Lastspitzen.
- Alarm-Korrelation: Mehrere Alarme, die dieselbe Ursache haben, werden zu einem einzigen Incident zusammengefasst, anstatt das Team mit Einzelmeldungen zu überhäufen.
- Automatische Priorisierung: KI bewertet, wie kritisch ein Alarm wahrscheinlich ist und welche Auswirkungen er haben könnte, bevor der erste Mensch eingreift.
Intelligente Alarmgruppierung und Korrelation
Wenn ein Datenbankserver ausfällt, können daraufhin Dutzende von abhängigen Diensten Fehler melden. Ohne Korrelation erhält das On-Call-Team zwanzig separate Alarme, obwohl es sich um ein einziges zugrunde liegendes Problem handelt. KI-gestützte Korrelationsmodelle erkennen solche kausalen Ketten und fassen verwandte Ereignisse zu einem gemeinsamen Incident zusammen.
Systeme wie Dynatrace Davis, PagerDuty AIOps oder Moogsoft setzen genau auf diesen Ansatz. Sie analysieren nicht nur Metriken, sondern auch Logs, Traces und topologische Abhängigkeiten zwischen Diensten. Das Ergebnis: Statt zwanzig Einzelalarmen bekommt das Team eine strukturierte Meldung mit dem Hinweis, dass ein Datenbankausfall achtzehn nachgelagerte Dienste betrifft – inklusive erster Informationen darüber, welche Dienste für den Endnutzer besonders spürbar beeinträchtigt sind.
Diese Korrelation ist besonders wertvoll, weil sie die kognitive Last in stressigen Situationen erheblich reduziert. Wer nachts für einen Incident geweckt wird, muss sofort handlungsfähig sein – und das fällt leichter, wenn das System bereits eine erste Lageeinschätzung liefert und nicht jede Folgediagnose manuell zusammengestellt werden muss.
Sprachmodelle für die automatische Erstbewertung
Seit der breiten Verfügbarkeit leistungsfähiger Sprachmodelle experimentieren immer mehr Betriebsteams mit LLM-gestützter Incident-Erstbewertung. Das Prinzip ist dabei vergleichsweise geradlinig: Wenn ein Alarm ausgelöst wird, aggregiert das System automatisch relevante Logs, aktuelle Metriken und Runbook-Einträge und übergibt diese Daten an ein Sprachmodell, das eine erste strukturierte Einschätzung formuliert.
Diese Einschätzung kann zum Beispiel Folgendes enthalten:
- Eine kurze Zusammenfassung des wahrscheinlichen Problems auf Basis der aktuellen Daten
- Hinweise auf ähnliche frühere Vorfälle aus der eigenen Incident-History
- Erste Diagnoseschritte aus dem relevanten Runbook
- Eine Einschätzung der wahrscheinlichen Auswirkungen auf Endnutzer oder nachgelagerte Systeme
Das On-Call-Mitglied bekommt damit keinen fertigen Lösungsvorschlag, wohl aber einen strukturierten Startpunkt – was besonders in den ersten chaotischen Minuten eines Incidents enormen Zeitgewinn bedeuten kann. Wichtig ist dabei stets: Diese LLM-Einschätzung ist ein Vorschlag zur Orientierung, keine verlässliche Diagnose. Die finale Bewertung liegt immer beim Menschen, der die Systeme kennt und die Auswirkungen einschätzen kann.
Praktische Umsetzung im Betrieb
Der effektive Einsatz von KI im Alerting setzt gute Eingangsdaten voraus. Modelle, die auf chaotischen oder inkonsistenten Metriken trainiert werden, liefern unzuverlässige Ergebnisse – Garbage in, garbage out gilt hier besonders deutlich. Bevor Teams KI-gestütztes Alerting einführen, lohnt es sich deshalb, die Grundlagen zu festigen: konsistente Metriklabels, strukturierte Logs im einheitlichen Format und eine gepflegte Service-Map mit dokumentierten Abhängigkeiten.
Als pragmatischer Einstieg empfiehlt sich die Aktivierung dynamischer Baselines, die viele Monitoring-Plattformen heute bereits eingebaut anbieten. Datadog, New Relic und Dynatrace bieten diese Funktion ohne zusätzliche Modellentwicklung. Teams müssen kein eigenes ML-Modell trainieren, um von dieser Funktionalität zu profitieren.
Parallel dazu lohnt sich eine regelmäßige Auditierung der eigenen Alarmlandschaft: Welche Alarme schlagen am häufigsten an? Wie viele davon resultieren in echten Incidents? Wie lange dauert es im Schnitt, bis ein Alarm acknowledged wird? Diese Kennzahlen zeigen, wo KI den größten Hebel hat – und wo zuerst manuelle Konfigurationsarbeit notwendig ist.
Grenzen von KI im Alerting
KI-gestütztes Alerting löst nicht alle Probleme. Einige wichtige Einschränkungen bleiben bestehen und sollten Teams bei der Einführung realistisch einkalkulieren:
- Cold-Start-Problem: Für neue Dienste oder nach größeren Architekturänderungen haben Modelle zu wenig historische Daten, um verlässliche Baselines zu lernen. In dieser Anlernphase sind manuelle Konfigurationen weiterhin notwendig.
- Neuartige Probleme: Ausfallmuster, die dem Modell völlig unbekannt sind, werden schlechter erkannt als bekannte Wiederholungsmuster. KI ist gut in der Erkennung bekannter Variationen, weniger gut bei echten Erstfällen.
- False Negatives: Zu aggressive Rauschunterdrückung kann dazu führen, dass echte Probleme übersehen werden. Das Tuning zwischen zu viel Alarm und zu wenig bleibt eine Daueraufgabe.
- Erklärbarkeit: Komplexe Modelle geben oft keine nachvollziehbare Begründung für ihre Bewertungen – was in kritischen Produktionssituationen problematisch sein kann, wenn Teams die KI-Entscheidung hinterfragen wollen.
Fazit: KI als Ergänzung, nicht als Ersatz
KI im Alerting ist kein Ersatz für solides Monitoring-Engineering, sondern eine wirkungsvolle Ergänzung. Teams, die ihre Grundlagen sauber aufgebaut haben – klare Alarmbeschreibungen, gepflegte Runbooks, strukturierte Eskalationspfade und regelmäßige Alert-Reviews – profitieren am stärksten von KI-gestützten Erweiterungen.
Der entscheidende Schritt nach vorne liegt nicht in einem einzelnen Tool, sondern in einer veränderten Herangehensweise: Alarme nicht nur als Schwellenwert-Auslöser zu betrachten, sondern als Signale, die im Kontext des Gesamtsystems bewertet werden müssen. KI kann dabei helfen, diesen Kontext automatisch herzustellen – und damit On-Call-Teams sowohl im Alltag als auch in akuten Incidents spürbar entlasten.
Quellen: Gartner AIOps Market Guide 2025; PagerDuty Engineering Blog; Dynatrace Davis AI Documentation; New Relic AI Monitoring Docs.
