Ein Knoten in einem Kubernetes -Cluster fällt aus.
Innerhalb von neunzig Sekunden hat Alertmanager eine Knotenwarnung, ein Dutzend Pod-Warnungen, eine Handvoll Workload-Warnungen und eine Warnung auf Namespace-Ebene ausgelöst. Ihr Incident-Tool eröffnet für jede einzelne davon ein Ticket. Ihr Bereitschaftstechniker wird fünfzehn Mal wegen eines einzigen Problems benachrichtigt und behandelt jede Benachrichtigung so, als wäre es die erste, da nichts in der Pipeline weiß, dass diese miteinander zusammenhängen.
Multiplizieren Sie das nun mit Dutzenden von Kundenumgebungen.
Die übliche Antwort ist ein Disziplinproblem, das als Ratschlag verpackt wird: Schreibt bessere Alarmregeln, passt eure Schwellenwerte an, fügt weitere Sperrregeln hinzu. Alles nützliche Tipps. Aber nichts davon lässt sich von sich aus skalieren, da das Volumen nicht unbedingt ein Symptom für schlechte Regeln ist.
Das ist ein Anzeichen dafür, dass jede Warnmeldung so behandelt wird, als verdiene sie dieselbe Reaktion.
Das tut es nicht.
Die Entscheidung, welche Warnmeldungen welche Reaktion erfordern, ist ein statistisches Problem, das mit Hilfe von Statistiken gelöst werden sollte, die Sie einsehen können.
Warnmeldungen sind keine Vorfälle
Das Wichtigste, was eine Pipeline für das Incident-Management richtig hinbekommen muss, ist die Unterscheidung.
Ein Alarm ist ein Signal, das anzeigt, dass eine Bedingung erfüllt ist. Ein Vorfall ist eine Arbeitseinheit für einen Mitarbeiter – etwas, das einen Verantwortlichen, einen Zeitrahmen, eine Lösung und eine SLA-Uhr hat.
Die meisten Tools fassen beides zusammen: eine Benachrichtigung und ein Ticket. Deshalb wird die Warteschlange unüberschaubar.
Die Pipeline, die wir entwickeln, betrachtet die Lücke zwischen beiden als ihre eigentliche Aufgabe:
ingest → normalize → fingerprint → TRIAGE → correlate → incident → notify → RCA → resolve → learn
Alles bis hin zum „Fingerprinting“ ist reine Buchhaltung – dabei werden heterogene Alarmdaten in eine standardisierte Form gebracht und jeder einzelne erhält eine feste Identität.
Alles, was nach der Korrelation folgt, ist Teil des Workflows – das Ticket in GLPI oder Jira, die Benachrichtigung, die Ursachenanalyse und die Behebung des Problems.
Der interessante Teil liegt in der Mitte: Triage und Korrelation, wobei die Plattform zunächst eine Frage beantwortet, bevor irgendetwas anderes geschieht:
Ist diese Meldung eine umfassende Untersuchung wert, und wie dringend ist diese?
Nicht jede Warnmeldung erfordert die gleiche Reaktion
Eine binäre Entscheidung nach dem Motto „Anrufen oder nicht anrufen“ ist zu pauschal.
Die Triage-Engine gibt vier Stufen aus:
| Stufe | Bedeutung | Was passiert? |
|---|---|---|
| SOFORT | Ich bin mir ziemlich sicher, dass das jetzt wichtig ist | Die Ursachenanalyse beginnt sofort |
| IN DER WARTEZEILE | Ist wichtig, aber nicht dringend | RCA beginnt innerhalb der SLA |
| ANSEHEN | Wahrscheinlich Rauschen, aber nicht bewiesen | Wird überwacht; eskaliert, falls das Problem anhält oder sich häuft |
| UNTERDRÜCKEN | Lärm | Erfasst, nie verloren – aber keine Tickets, Seiten oder KI-Kosten |
Bei dieser letzten Spalte lohnt es sich, einen Moment innezuhalten.
Die Triage erfolgt vor dem kostspieligen, auf LLM basierenden Untersuchungsschritt. Jeder Alarm, der in den Status „WATCH“ oder „SUPPRESS“ statt in „IMMEDIATE“ gelangt, ist ein Modellaufruf, für den Sie nicht bezahlt haben.
Eine bessere Triage bedeutet nicht nur weniger Seiten. Sie ist ein direkter, messbarer Hebel für die Kosten jedes Vorfalls, den die KI tatsächlich untersucht.
So funktioniert die automatisierte Alarm-Triage
Die Engine besteht aus einer mehrstufigen Pipeline. Jede Stufe kann vom Bediener unabhängig geschaltet und angepasst werden, und keine davon erzeugt ein „Black-Box“-Ergebnis.
1. Deduplizierung und Rauschunterdrückung
Erstens: Wiederholungen derselben Warnmeldung für denselben Fingerabdruck werden zusammengefasst.
Lassen Sie dann alles, was unter einem einstellbaren „Interessen“-Schwellenwert liegt, fallen, bevor Sie weitere Rechenleistung dafür aufwenden.
Dadurch werden offensichtliche Wiederholungen entfernt, bevor die aufwändigere statistische Auswertung beginnt.
2. Entropiebasierte Bewertung von Warnmeldungen
Im nächsten Schritt kommen Methoden aus veröffentlichten, von Fachkollegen anerkannten Forschungsarbeiten zur Alarm-Triage zum Einsatz.
Die zeitliche Entropie gibt an, wie ungewöhnlich ein Aktivitätsmuster ist. Ein Herzschlag, der alle fünf Minuten auftritt, erhält einen Wert nahe Null; etwas, das noch nie zuvor aufgetreten ist, erhält einen Wert nahe Eins.
Die semantische Entropie misst, wie spezifisch der Alarmtext ist, wobei ein einfaches TF-IDF-Verfahren auf Ihr eigenes Alarmkorpus angewendet wird. „Host down“ ist allgemein gehalten und erzielt einen niedrigen Wert; „OOMKilled postgres-primary“ ist spezifisch und erzielt einen hohen Wert.
Es gibt weder ein trainiertes Modell noch ein Anbieter-Vokabular. Die Bewertung wird anhand Ihrer bisherigen Daten automatisch aktualisiert.
Ein dritter Scorer, die topologiebewusste Entropie, steht zur Verfügung, sobald die Plattform über eine Abhängigkeitskarte verfügt.
3. Bayessche Signalfusion
Als Nächstes tragen fünf Beweisarten mit ihren Wahrscheinlichkeiten zu einer aktuellen a-posteriori-Verteilung bei:
- Schweregrad und SLO-Verbrauchsrate
- Alarm-Sturm-Erkennung – wie viele Alarme werden ausgelöst, wie schnell und an welcher Stelle in der Kaskade befindet sich dieser Alarm?
- Auswirkungsbereich – wie viele Namespaces betroffen sind und ob gemeinsame Infrastruktur beteiligt ist
- Komponentenschicht – Ausfälle in der Infrastruktur oder auf der Datenebene erhalten eine höhere Priorität als Ausfälle auf Anwendungsebene
- Historischer Kontext – ob dieser Alarmtyp bereits Auswirkungen hatte, wie häufig er aufgetreten ist und ob ein Runbook vorhanden ist
Jede Wahrscheinlichkeit ist eine Zahl, die Sie sehen und bearbeiten können.
Der Kaltstart-A-Prior beträgt 0,30. Nach jeder behobenen Störung werden die A-Prioren für diesen Alarmtyp anhand der tatsächlichen Ereignisse aktualisiert.
4. Rangliste der Eskalationsgeschwindigkeit mit Überlebensanalyse
Die Bayes’sche Bewertung gibt Aufschluss darüber, ob eine Warnmeldung beachtet werden muss.
In der nächsten Phase wird festgelegt, in welcher Reihenfolge Warnmeldungen innerhalb einer Ebene bearbeitet werden sollen.
Ein Cox-Proportional-Hazards-Modell wird anhand Ihrer Historie gelöster Vorfälle trainiert, um zu ermitteln, welche Merkmale am schnellsten vorhersagen, ob eine Warnmeldung zu einer SLO-Verletzung oder einem P1-Vorfall führt.
Die Ausgabe bleibt gut lesbar: eine Tabelle mit Hazard-Ratios und deren Signifikanz, zum Beispiel:
„Gemeinsam genutzte Infrastruktur: 3,1-mal schnellere Eskalation.“
Es gibt eine wichtige Einschränkung: Es müssen zunächst drei bis sechs Monate lang Vorfälle gelöst worden sein – etwa 200 oder mehr –, bevor das System trainiert werden kann.
Das ist keine Funktion, die vom ersten Tag an verfügbar ist, und das sagen wir auch ganz offen.
5. Korrelation und Clusterbildung von Warnmeldungen
Hier werden verwandte Meldungen zu einem einzigen Vorfall zusammengefasst, statt zu fünfzehn.
Fünf austauschbare Strategien können in der von Ihnen festgelegten Reihenfolge ausgeführt werden, wobei die erste, die ein Treffer ergibt, den Vorrang hat:
- Deterministische Regeln für bekannte wiederkehrende Muster, wie beispielsweise „derselbe Host + dieselbe Überprüfung innerhalb von 15 Minuten“
- Zeitfenster-Nähe bei Stürmen unbekannter Herkunft
- Topologiebewusste Gruppierung, sobald eine Abhängigkeitskarte vorliegt
- ML-Ko-Occurrence, sobald genügend historische Daten vorliegen
- Menschliches Feedback: Lernen aus den Zusammenführungs- und Aufteilungsaktionen der Bediener im Laufe der Zeit
Das Ergebnis ist eine Verlagerung vom Alert-Aufkommen hin zum Kontext des Vorfalls.
Überprüfen Sie die Einstellung, bevor Sie das Gerät einschalten
Das ist der Aspekt, den wir für am wichtigsten halten – und der in vielen AIOps-Tools fehlt.
Jede Änderung an der Triage-Konfiguration – sei es eine Gewichtung, ein Schwellenwert oder ein neues Korrelationsrezept – kann anhand Ihrer tatsächlichen historischen Warnmeldungen simuliert werden, bevor sie angewendet wird.
Wählen Sie die letzten 7 oder 30 Tage aus. Die Plattform zeigt die aktuelle Konfiguration und die vorgeschlagene Konfiguration nebeneinander an:
| Stufe | Aktuell | Vorgeschlagen |
|---|---|---|
| SOFORT | 142 | 89 (▼37 %) |
| IN DER WARTEZEILE | 203 | 241 |
| ANSEHEN | 89 | 94 |
| UNTERDRÜCKEN | 566 | 576 |
| Rauschverhältnis | 34% | 41% |
| Geschätzte Falschmeldung SOFORT | 28 | 12 |
Beispielabbildungen aus dem Entwurf, keine Kundendaten.
Die Gesamtzahlen geben nur einen Teil des Gesamtbildes wieder.
Die Plattform zeigt außerdem einzelne Warnmeldungen an, deren Einstufung sich ändern würde, sodass Sie die Neueinstufungen überprüfen können:
„SlowDBQuery, Produktion, achtmal täglich: QUEUED → SUPPRESS“
im Vergleich zu:
„PodCrashLoop am API-Gateway: WATCH → IMMEDIATE“
Man sieht die einzelnen Veränderungen und nicht nur eine allgemeine Verbesserung.
Und in der Produktion ändert sich nichts, bis Sie den Nachweis haben, dass die vorgeschlagene Konfiguration tatsächlich hilft.
Die Sicherheitsgeländer rund um die automatisierte Triage
Durch Gruppierung und Unterdrückung kann ein tatsächlicher Vorfall verdeckt werden, wenn diese falsch angewendet werden. Daher verfügt die Pipeline über mehrere Sicherheitsvorkehrungen:
- „SUPPRESS“ bedeutet „protokolliert“, nicht „gelöscht“. Jede Warnmeldung bleibt erhalten und kann abgefragt werden. Die Stufe legt fest, was die Warnmeldung auslöst, nicht, ob sie existiert.
- Zunächst der Schattenmodus. Die Korrelationsanalyse läuft über Wochen hinweg und liefert Ergebnisse, die nichts ändern. Die Plattform vergleicht die Abweichungen mit dem tatsächlichen Verhalten der Betreiber, bevor sie einem bestehenden Vorfall ein Symptom zuordnet, anstatt einen neuen Vorfall zu eröffnen.
- Eine kritische Warnmeldung zu einer Entität, für die keine weiteren Alarme vorliegen, wird niemals unterdrückt. Eine Gruppierungsregel darf das erste Anzeichen eines neuen Problems nicht ausblenden.
- Jede Tier-Entscheidung wird zusammen mit den Signalen und Werten protokolliert, die zu ihr geführt haben. Wenn ein Ingenieur fragt: „Warum wurde ich hier nicht benachrichtigt?“, gibt es eine Antwort darauf.
Außerdem gibt es eine Auswirkung auf die Berichterstattung, die es zu berücksichtigen gilt.
Sobald Symptome Vorfällen zugeordnet werden, anstatt separate Tickets zu eröffnen, sinkt die Anzahl der Vorfälle. Alle SLA- oder DORA-Berichte, die auf der Anzahl der Tickets basieren, werden sich entsprechend ändern.
Das ist der springende Punkt, aber das muss schon vor der Inbetriebnahme des Systems klar sein – und darf nicht erst bei einer vierteljährlichen Überprüfung festgestellt werden.
Was wir als Erstes entwickeln
Es handelt sich hierbei um eine schrittweise Umsetzung, und wir möchten lieber konkret als vage bleiben. Diese Funktionen werden im Rahmen der ITGix AIOps-Plattformentwickelt, wobei die automatisierte Alarmtriage eine Ebene eines umfassenderen Workflows zur Behebung von Vorfällen darstellt.
Der nächste Schritt umfasst Deduplizierung, bayessche Bewertung sowie regel- und zeitfensterbasierte Korrelation.
Die Entropie-Bewertung erfolgt, sobald ein Korpus aus einigen Wochen mit Warnmeldungen als Grundlage vorliegt.
Die Rangfolge der Überlebensanalyse wird nur aktiviert, wenn für eine Umgebung genügend Daten zur Geschichte der aufgeklärten Vorfälle vorliegen.
Die topologiebewusste Korrelation hängt von der Service-Abhängigkeitskarte ab – dem Thema des nächsten Beitrags.
Das Lernen durch menschliches Feedback ist der Teil mit dem längsten Zeithorizont.
Testen Sie die automatisierte Triage von Warnmeldungen anhand Ihrer eigenen Daten
Der Simulationsmodus ist die Demo.
Keine Folie. Ihre tatsächlichen Warnmeldungen der letzten 30 Tage, die durch die Pipeline wiedergegeben werden, wobei die Vorher- und Nachher-Stufen auf dem Bildschirm angezeigt werden.
Wenn der Lärm nicht nachlässt, hast du nichts verloren.
Falls ja, hast du die Zahl gesehen, bevor du dich zu irgendetwas verpflichtet hast.
Behalten Sie die ITGix-Blogs im Auge, um das nächste Kapitel nicht zu verpassen.
