BLUF: Korrelationsbasiertes AIOps verdichtet eine Alarmflut zu einer Situation; kausales AIOps benennt eine einzelne Ursachen-Entität. Das sind zwei verschiedene Produkte für zwei Hälften desselben Problems, und Anbieter vermarkten beide unter derselben Bezeichnung. Korrelations-Engines berichten Kompressionsraten — bei auf Genauigkeit ausgelegter Konfiguration typischerweise 70 bis 85 Prozent —, lassen die Ursache aber als Rangliste von Kandidaten offen. Kausale Engines durchlaufen eine Abhängigkeitstopologie mittels Fehlerbaumanalyse und liefern eine Ursache plus Wirkungsradius. Das funktioniert nur, solange diese Topologie vollständig ist. Fehlende Abhängigkeitskanten erzeugen keine Fehlermeldung. Sie degradieren eine kausale Engine still zu einer teuren Korrelations-Engine. Bevor Sie eines von beiden beschaffen, spielen Sie Ihre eigene Incident-Historie gegen beide Verfahren erneut ab.
Die beiden Engines sind keine konkurrierenden Umsetzungen derselben Idee
Ein Produktionsvorfall erzeugt eine Alarmflut, weil Monitoring geschichtet ist: ein Infrastruktur-Agent, ein APM-Werkzeug, ein synthetischer Check und ein logbasierter Alarm beobachten denselben Fehler aus unterschiedlichen Perspektiven, und jede abhängige Komponente meldet ihr eigenes Symptom. Ein einzelnes Datenbank-Saturationsereignis kann in einer mittelgroßen Landschaft plausibel mehrere Hundert Alarme auslösen.
Zwei unterschiedliche Mechanismen reduzieren diese Flut, und der Unterschied ist architektonisch, nicht eine Frage der Modellqualität.
Korrelation gruppiert Alarme, die gemeinsam auftreten. Die Gruppierungssignale sind zeitliche Nähe, gemeinsame Tags oder Entitätskennungen, textliche Ähnlichkeit und historisch gelerntes gemeinsames Auftreten. Das Ergebnis ist ein Cluster — bei Datadog ein Case, bei BigPanda ein Incident, bei Dynatrace ein Problem — üblicherweise mit einer Rangliste wahrscheinlicher Ursachen. Die Engine behauptet, dass diese Alarme zusammengehören. Sie behauptet nicht, warum.
Kausale Analyse durchläuft einen Abhängigkeitsgraphen. Sie beginnt bei den beobachteten Anomalien, folgt den bekannten Beziehungen zwischen Diensten, Prozessen, Hosts, Containern und Netzwerkpfaden und wendet Fehlerbaumanalyse an, um vom Systemfehler zurück auf den Komponentenfehler zu schließen. Das Ergebnis ist eine als Ursache identifizierte Entität plus eine Wirkungsmenge. Dynatrace dokumentiert das ausdrücklich: die kausale KI nutzt Fehlerbaumanalyse über Abhängigkeitsinformationen aus Smartscape, OneAgent und Cloud-Integrationen, um Millionen von Abhängigkeiten zu analysieren und zur wahrscheinlichsten Ursache zu kommen. Die Root-Cause-Dokumentation stellt unmissverständlich fest, dass zeitliche Korrelation allein nicht ausreicht.
Die Formulierung des Anbieters lohnt genaues Lesen. Dynatrace beschreibt korrelationsbasierte KI als probabilistisch und auf menschliche Verifikation angewiesen, kausale KI hingegen als faktenbasiert und damit zu automatisierten Analysen fähig. Das ist eine Aussage über Determinismus bei vollständigem Kontextmodell — keine Aussage darüber, dass die Topologie immer vollständig sei.
Wo jede Engine in der Verarbeitungskette sitzt
Stufe 1 — Rohereignisse. Jede Monitoring-Quelle sendet. Volumen: der vollständige Strom. Keine Engine hat bisher gewirkt. Praxisberichte beschreiben regelmäßig, dass Filterung 60 bis 80 Prozent des Rohvolumens entfernt, bevor Korrelation überhaupt beginnt. Das ist wichtig zu wissen, weil diese Reduktion häufig in die beworbene Rauschreduktionszahl eingerechnet wird.
Stufe 2 — Normalisierung und Deduplizierung. Wiederholungen desselben Alarms fallen zusammen. Allein diese Stufe erzeugt sehr hohe Prozentwerte und ist der am wenigsten intelligente Teil der Kette. Behandeln Sie jede Rauschreduktionsangabe, die Deduplizierung einschließt, als Marketing-Arithmetik und nicht als Analysequalität.
Stufe 3 — Korrelation. Alarme gruppieren sich zu Situationen. BigPanda formuliert hier ungewöhnlich offen: Kompression ist die primäre Kennzahl, die Rate nähert sich idealerweise 100 Prozent, doch perfekte Raten beeinträchtigen die Genauigkeit und erzeugen falsche Gruppierungen oder übersehene Zusammenhänge — der praktische Zielbereich liegt deshalb bei 70 bis 85 Prozent. Lesen Sie das als eingestandenen Genauigkeitskompromiss eines Anbieters, dessen Produkt Korrelation ist.
Stufe 4 — Kausale Traversierung. Die Situation wird auf die Abhängigkeitstopologie abgebildet und auf eine Ursachen-Entität mit Wirkungsradius reduziert. Diese Stufe verändert die Diagnosezeit, nicht das Triage-Volumen.
Stufe 5 — Wirkung und Priorisierung. Die Impact-Analyse von Dynatrace identifiziert betroffene Einstiegsdienste, die Gesamtzahl betroffener Entitäten, die Anzahl betroffener Service Level Objectives und die Anzahl potenziell betroffener realer Nutzer. Das ist die Ausgabe, mit der eine Rufbereitschaft die Reihenfolge entscheidet, nicht nur die Ursache.
Die betrieblich entscheidende Folge: Stufen 2 und 3 verändern, wie viele Objekte ein Mensch ansieht. Stufe 4 verändert, wie lange dieser Mensch braucht, um zu entscheiden, was zu reparieren ist. Wer beides vermischt, beschafft eine Kompressions-Engine und erwartet eine Diagnose-Engine.
Entscheidungstabelle: welche Engine Ihre Incident-Historie rechtfertigt
Symptom in Ihren Daten: Die Rufbereitschaft erhält Dutzende Tickets pro Vorfall, viele Duplikate, unklare Zuständigkeit. — Dominanter Kostenblock: Triage und Routing. — Beschaffen: zuerst Korrelation, Deduplizierung und Anreicherung. — Kennzahl, die sich bewegen muss: Kompression von Alarmen zu Incidents, Duplikat-Tickets pro Vorfall, fehlgeleitete Tickets.
Symptom: ein Ticket pro Vorfall, aber der Krisenraum diskutiert 40 Minuten, welche Komponente schuld ist. — Dominanter Kostenblock: Diagnose. — Beschaffen: kausale Topologieanalyse. — Kennzahl: Zeit von der Annahme bis zur korrekten Komponentenidentifikation sowie Anzahl der pro Vorfall einbezogenen Teams.
Symptom: Die Ursache ist meist offensichtlich, aber niemand weiß, wer betroffen ist oder ob ein Großvorfall erklärt werden muss. — Dominanter Kostenblock: Wirkungsbewertung. — Beschaffen: topologiegestützte Impact- und Blast-Radius-Analyse. — Kennzahl: Zeit bis zur belastbaren Kundenwirkungsaussage, Anzahl fehlerhafter Großvorfall-Erklärungen.
Symptom: Alarme feuern für Zustände, die nie relevant waren. — Dominanter Kostenblock: Alarmdesign, nicht Analyse. — Beschaffen: zunächst nichts. Rationalisieren Sie Schwellwerte und Zuständigkeiten; eine AIOps-Engine über nicht rationalisiertem Alarmierungsbestand industrialisiert das Rauschen.
Symptom: Vorfälle wiederholen sich mit gleicher Ursache, und niemand erkennt das Muster. — Dominanter Kostenblock: Problemmanagement. — Beschaffen: Erkennung wiederkehrender Muster über einem Incident-Historienspeicher. — Kennzahl: Anteil der Vorfälle mit Zuordnung zu einem bekannten Muster, Wiederholungsrate.
Eine Beobachtung sollte diese Tabelle disziplinieren: Beschaffen Sie gegen die Stufe, die Ihre eigene Incident-Historie als teuer ausweist. Anbieter-Benchmarks entstehen auf der Referenztopologie des Anbieters, die konstruktionsbedingt vollständig ist.
Die Topologie-Abhängigkeit: warum kausale Präzision leise verfällt
Eine kausale Engine ist eine Graphtraversierung. Ihre Genauigkeit ist durch die Genauigkeit des Graphen begrenzt. Das ist die folgenreichste und am wenigsten diskutierte Eigenschaft dieser Produktkategorie.
Fehlt eine Abhängigkeitskante — ein undokumentierter synchroner Aufruf zwischen zwei Diensten, ein gemeinsam genutztes Speicher-Backend, das kein Agent meldet, ein Netzwerkpfad außerhalb des instrumentierten Perimeters, eine Drittanbieter-API, die die Topologie als Blattknoten modelliert —, kann die Traversierung sie nicht überschreiten. Die Engine meldet keine Lücke. Sie liefert die tiefste erreichbare Ursache innerhalb des ihr bekannten Graphen, mit derselben souveränen Darstellung wie eine korrekte Antwort. Funktional haben Sie kausale Analyse bezahlt und Korrelation in besserer Verpackung erhalten.
Drei praktische Quellen unvollständiger Topologie in Unternehmenslandschaften. Erstens Abdeckungsasymmetrie: automatische Discovery über Agenten ist für instrumentierte Workloads ausgezeichnet und blind für alles ohne Agent — Legacy-Maschinen, Appliances, Managed Services, OT-Netze. Zweitens semantische Lücken: zwei Systeme können über einen Geschäftsprozess oder eine Datenübergabe tatsächlich abhängig sein, ohne dass ein Laufzeit-Aufrufgraph dies zeigt. Drittens Veralterung: aus beobachtetem Verkehr abgeleitete Topologie verfällt für seltene Pfade, sodass der monatliche Batch-Lauf als Abhängigkeit gar nicht erscheint.
In industriellen und OT-nahen Umgebungen ist das Abdeckungsproblem strukturell und kein Konfigurationsversäumnis, weil Agenten auf Leitsystem-Assets nicht frei installierbar sind. Genau deshalb muss die Evidenzschicht bewusst aufgebaut werden — der Ansatz, den ich in OT-Observability für AIOps: passive, zeitgenaue Evidenz vor der Automatisierung beschrieben habe — und deshalb brauchen Abhängigkeitssemantiken einen expliziten Vertrag statt Inferenz, wie in Warum industrielle KI am Datenvertrag scheitert dargelegt.
Fehlermodi, mit denen Sie rechnen sollten
1. Überkompression verdeckt einen zweiten gleichzeitigen Vorfall. Zwei unabhängige, zeitlich überlappende Störungen werden zu einer Situation, einem Ticket und einem zugewiesenen Team verschmolzen. Der zweite Vorfall bleibt unsichtbar, bis ein Kunde ihn meldet. Erkennung: prüfen Sie verschmolzene Situationen, die Alarme von Entitäten ohne topologischen Pfad zueinander enthalten. Gegenmaßnahme: Gruppierung nach topologischer Distanz begrenzen, nicht nur nach Zeitfenster.
2. Doppelte Probleme durch asynchrone Datenankunft. Dynatrace dokumentiert das offen: weil Beobachtungsfenster, Zeitpläne synthetischer Checks und Latenzen der Datenquellen abweichen, kann die Ursachenerkennung zwei Probleme mit derselben Ursache erzeugen; Duplikate werden bewusst akzeptiert, um schnelle Alarmierung zu erhalten. Sie werden mit einer Duplikat-Markierung gekennzeichnet. Ignoriert Ihre Ticketing-Integration diese Markierung, erzeugen Sie zwei Tickets und zwei Bearbeiter pro Vorfall. Gegenmaßnahme: die Duplikat-Markierung in der Ticketing-Integration auswerten, nicht in einem Dashboard.
3. Analyseverzögerung wird als Erkennungsverzögerung fehlinterpretiert. Dynatrace hält ein neu erkanntes Problem in einem Verarbeitungszustand — typischerweise bis zu drei Minuten —, während die kausale KI entscheidet, ob es in ein größeres Problem einzuordnen ist, und unterdrückt bis dahin Alarme. Das ist ein bewusster Kompromiss zwischen Genauigkeit und Latenz. Teams, die Erkennungszeit ab der Benachrichtigung messen, rechnen diese Minuten der Erkennung zu und deaktivieren möglicherweise die kausale Verarbeitung, um eine Kennzahl zu verschönern — Korrektheit gegen Optik getauscht. Gegenmaßnahme: Erkennung ab dem Zeitstempel der ersten Anomalie messen, nicht ab der ersten Benachrichtigung.
4. Die Ursache ist technisch korrekt und betrieblich nutzlos. "Knotensaturierung auf Host X" ist eine korrekte Ursache und eine nutzlose Handlungsanweisung, wenn die eigentliche Behebung das Zurückrollen des Deployments ist, das das Lastprofil verändert hat. Gegenmaßnahme: Änderungsereignisse in den Topologiekontext aufnehmen, damit Deployments und Konfigurationsänderungen Ursachenkandidaten sind und nicht nur Infrastrukturzustände.
5. Zuversicht ohne Kalibrierung. Eine Kandidatenrangliste, die als eine Antwort präsentiert wird, erzieht Bearbeiter dazu, das Mitdenken einzustellen. Gegenmaßnahme: den Traversierungspfad im Incident-Datensatz ausweisen und messen, wie häufig die höchstplatzierte Ursache mit dem Ergebnis der Nachbetrachtung übereinstimmte. Wer diese Zahl nicht berechnen kann, kann keine kausale Genauigkeit behaupten.
6. Automatisierung auf unkalibrierter Ursache. Automatisierte Behebung, die an ein Ursachen-Label gekoppelt ist, führt bei falschem Label souverän das falsche Runbook aus. Behalten Sie die Freigabestufe, bis die Genauigkeitszahl existiert — das Muster, das ich in Industrielle AIOps-Incident-Automation: von Alert-Rauschen zu freigegebener Remediation dargestellt habe.
Eine Replay-Evaluierung, die Sie vor jeder Unterschrift durchführen können
Proof-of-Concepts von Anbietern laufen vorwärts in der Zeit auf einer ruhigen Landschaft und beweisen fast nichts. Spielen Sie stattdessen Ihre eigene Historie erneut ab. Der Aufwand liegt bei etwa zwei Ingenieurwochen und ist der wirkungsvollste verfügbare Beschaffungsschritt.
Schritt 1. Wählen Sie 20 bis 30 abgeschlossene Vorfälle mit dokumentierter Ursache aus der Nachbetrachtung, bewusst einschließlich mindestens fünf teamübergreifender Vorfälle, zwei zeitlich überlappender Vorfälle und drei Fälle, in denen die Ursache eine Änderung und kein Ressourcenzustand war. Kleine, gegnerisch ausgewählte Stichproben schlagen große, einfache.
Schritt 2. Extrahieren Sie den vollständigen Rohalarmstrom für jedes Vorfallfenster, vor jeder Filterung, aus allen Monitoring-Quellen. Wenn Sie das nicht rekonstruieren können, ist das Ihr erstes Ergebnis: Sie haben keine Basislinie, gegen die eine Anbieterangabe prüfbar wäre.
Schritt 3. Erfassen Sie die Referenzwahrheit je Vorfall: Ursachen-Entität, Zeitstempel der ersten Anomalie, Zeitpunkt der korrekten Komponentenidentifikation aus Chat- oder Ticketverlauf, sowie die Menge der betroffenen Dienste.
Schritt 4. Spielen Sie durch jede Kandidatenplattform ab und erfassen Sie vier Zahlen je Vorfall: eingehende Alarme, ausgehende Incidents, ob die höchstplatzierte Ursache der Referenzwahrheit entspricht, und ob die gemeldete Wirkungsmenge den bekannten betroffenen Diensten entspricht.
Schritt 5. Bewerten Sie auf Portfolioebene. Die Top-1-Ursachengenauigkeit ist die entscheidende Zahl — der Anteil der Vorfälle, in denen die höchstplatzierte Ursache korrekt war. Eine Plattform mit 90 Prozent Kompression und 45 Prozent Top-1-Genauigkeit ist ein Triage-Werkzeug. Eine mit 70 Prozent Kompression und 85 Prozent Top-1-Genauigkeit ist ein Diagnosewerkzeug. Beides kann beschaffungswürdig sein; sie sind keine Substitute.
Schritt 6. Messen Sie die Topologievollständigkeit unabhängig vom Anbieter. Ziehen Sie 30 bekannte Abhängigkeiten aus Architekturdokumentation und Änderungsprotokollen und prüfen Sie, ob jede als Kante in der ermittelten Topologie der Plattform erscheint. Die Fehlerquote ist die praktische Obergrenze der kausalen Genauigkeit — und eine Zahl, die Ihnen gehört und nicht vom Anbieter berichtet wird.
Prüfliste vor der Inbetriebnahme
— Top-1-Ursachengenauigkeit auf Ihren eigenen wiederabgespielten Vorfällen gemessen, mit dokumentierter Stichprobenzusammensetzung.
— Topologie-Fehlerquote gegen eine dokumentierte Abhängigkeitsstichprobe gemessen, mit benannten Lücken und je einem Verantwortlichen.
— Segmente ohne Agenten und OT-Segmente ausdrücklich als außerhalb des kausalen Traversierungsumfangs ausgewiesen, damit niemand einer Ursache innerhalb eines blinden Bereichs vertraut.
— Änderungsereignisse (Deployments, Konfiguration, Infrastructure-as-Code-Anwendungen) als vollwertiger Topologiekontext eingelesen.
— Duplikat-Markierungen von der Ticketing-Integration ausgewertet, durch einen Test verifiziert, der ein Duplikat erzeugt.
— Erkennungszeit ab dem Zeitstempel der ersten Anomalie gemessen, Analyseverzögerung separat berichtet.
— Traversierungspfad in jedem Incident-Datensatz gespeichert, plus regelmäßiger Bericht, der die höchstplatzierte Ursache gegen die Ergebnisse der Nachbetrachtung stellt.
— Automatisierte Behebung hinter menschlicher Freigabe, bis die Top-1-Genauigkeit gemessen und über mindestens ein Quartal stabil ist.
Kompromisse, klar benannt
Kausale Analyse kostet Instrumentierungstiefe. Ihre Präzision wird mit Agentenabdeckung, Trace-Propagierung und einem gepflegten Abhängigkeitsmodell bezahlt. In einer heterogenen Landschaft mit Zukäufen, Appliances und OT-Segmenten ist vollständige Abdeckung nicht erreichbar, und ein hybrider Entwurf — kausal dort, wo die Topologie belastbar ist, Korrelation mit ausdrücklicher menschlicher Diagnose im Rest — ist die redliche Architektur.
Korrelation kostet Genauigkeit bei hoher Kompression. Die Anbieterempfehlung, die Kompression bei 70 bis 85 Prozent zu halten statt gegen 95 zu treiben, ist eine Warnung und keine zu überwindende Beschränkung.
Beides kostet Betriebsdisziplin. Keine der Engines verbessert eine Landschaft, in der Alarmschwellen ohne Eigentümer und ohne Rationalisierung existieren; sie verarbeiten dasselbe Rauschen nur schneller. Und keine ersetzt die Zuverlässigkeitsarbeit, die Google SRE als Governance-Aufgabe fasst: strikte Leitplanken, Dry-Run-Unterstützung, progressive Autorisierung und fortlaufende Evaluierung, bevor autonom in Produktion gehandelt wird. Eine unverifizierte Ursache ist eine schlechte Grundlage für einen autonomen Behebungsagenten, unabhängig davon, was auf dem Anbieteretikett steht.
Nächste Schritte
Wenn Sie in diesem Quartal eine AIOps-Plattform evaluieren, führen Sie die Replay-Evaluierung vor dem Anbietervergleich durch. Zwanzig Vorfälle, je vier Zahlen, plus eine unabhängig gemessene Topologie-Fehlerquote sagen mehr aus als jede Referenzarchitektur — und sie verwandeln eine Funktionsdiskussion in eine Messdiskussion, die als einzige eine Vorfallnachbetrachtung übersteht.
Wenn Sie ein zweites Paar Augen auf den Replay-Entwurf, die Stichprobenzusammensetzung oder die Bewertung der Topologielücken für eine Landschaft mit Segmenten ohne Agenten oder OT-Anteilen wünschen: Genau diese Abgrenzung erarbeite ich mit Engineering- und Betriebsteams. Nehmen Sie über die Kontaktseite Verbindung auf und bringen Sie Ihre Incident-Historie mit — sie ist das Artefakt, auf dem die gesamte Entscheidung ruht.
Quellen
Dynatrace, "What is causal AI? Why this deterministic AI approach is critical to business success" — Fehlerbaumanalyse, Vergleichstabelle Korrelation gegen Kausalität (dynatrace.com/news/blog/what-is-causal-ai-deterministic-ai).
Dynatrace Docs, "Root cause analysis" und "Root cause analysis concepts" — kausale Topologie, Unzureichendheit zeitlicher Korrelation, Impact- und Blast-Radius-Analyse, doppelte Probleme, Verarbeitungszustand (docs.dynatrace.com/docs/dynatrace-intelligence/root-cause-analysis).
BigPanda, "AIOps event correlation software" — Kompression als primäre Kennzahl, der auf Genauigkeit ausgelegte Zielbereich 70 bis 85 Prozent, Stufen der Korrelationskette (bigpanda.io/blog/event-correlation).
Datadog Docs, "Intelligent Correlation" — Aggregation von Alarmen zu Cases auf Basis von Infrastrukturabhängigkeiten und zugrunde liegender Telemetrie sowie die ausdrückliche Einschränkung, dass unzureichende Telemetrie keine korrelierten Cases ergibt (docs.datadoghq.com/service_management/events/correlation/intelligent).
Google SRE, "AI in SRE: How Google is Engineering the Future of Reliable Operations" — Safety Trifecta, progressive Autorisierung, verpflichtender Dry-Run und fortlaufende Evaluierung für KI im Produktionsbetrieb (sre.google/resources/practices-and-processes/ai-engineering-reliable-operations).
