Anomalie-Erkennung mit saisonalen Baselines und kausaler KI

Was ist Anomalie-Erkennung in der Observability?

Anomalie-Erkennung ist das automatische Erkennen von Verhalten, das vom Normalzustand eines Systems abweicht. In der Observability bedeutet das: ungewöhnliche Werte in Metriken, Logs und Traces finden – etwa einen Latenzanstieg auf einem Endpoint, ein neues Fehlermuster in den Logs oder einen Rückgang abgeschlossener Bestellungen –, ohne dass vorher jemand für jedes Signal einen festen Schwellenwert definiert hat.

Statische Schwellenwerte funktionieren für wenige, gut verstandene Signale wie eine Festplattenbelegung über 90 Prozent. Für die meisten anderen versagen sie. Request-Raten folgen Tages- und Wochenzyklen, Batch-Jobs erzeugen vorhersehbare Spitzen, und jeder Service hat sein eigenes „normal“. Ein Schwellenwert, der um drei Uhr nachts Probleme erkennt, feuert mittags ständig; einer, der mittags ruhig bleibt, übersieht nachts ein echtes Problem. Anomalie-Erkennung ersetzt diese Schätzungen durch gelernte Baselines.

Warum Anomalie-Erkennung wichtig ist

Moderne Systeme erzeugen Millionen von Zeitreihen. Kein Team kann für alle Alerts von Hand pflegen. In der Praxis wird daher der Großteil gar nicht überwacht, und der überwachte Teil erzeugt Rauschen. Beides führt zum selben Ergebnis: Incidents werden spät entdeckt, oft von Kunden, und das On-Call-Team gewöhnt sich daran, Alerts zu ignorieren.

Gute Anomalie-Erkennung verschiebt dieses Verhältnis. Sie deckt standardmäßig jeden Service und jeden Endpoint ab, alarmiert nur bei tatsächlich ungewöhnlichen Abweichungen und erkennt schleichende Verschlechterungen, die nie eine harte Grenze überschreiten. In Kombination mit Korrelation wird aus einem Sturm von Symptomen ein einzelnes Problem – die Voraussetzung für eine kurze Mean Time to Resolve.

Saisonale Baselines und relevante Signale

Eine Baseline beschreibt den erwarteten Wertebereich eines Signals zu einem bestimmten Zeitpunkt. Obseria Intelligence lernt Baselines mit Tages- und Wochensaisonalität: Eine Lastspitze am Montag um 9 Uhr wird mit früheren Montagvormittagen verglichen, nicht mit dem Gesamtdurchschnitt. Baselines passen sich laufend an. Verändert ein Release das Verhalten dauerhaft, zieht das Modell nach, statt endlos zu alarmieren.

Besonders profitieren folgende Signale:

• Golden Signals je Service und Endpoint: Latenz, Traffic, Fehler und Sättigung.
• Log-Muster: neue oder plötzlich häufige Nachrichtenvorlagen, automatisch gruppiert.
• Infrastrukturmetriken wie CPU-Throttling, Speicherwachstum, Queue-Tiefe und Auslastung von Connection Pools.
• Frontend-Erlebnis aus RUM, etwa Core Web Vitals oder JavaScript-Fehlerraten pro Region.
• Business-KPIs wie Bestellungen, Registrierungen oder Zahlungen – oft das erste sichtbare Symptom.

So erkennt und erklärt Obseria Anomalien

Obseria Intelligence kombiniert kausale, prädiktive und generative KI. Die Erkennung ist nur der erste Schritt. Jede Anomalie wird im Abhängigkeitsgraphen verortet, den Obseria TopoGraph automatisch aus Traces, Agents und Cloud-APIs aufbaut. Wird eine Datenbank langsam und zeigen fünf aufrufende Services höhere Latenz, erhalten Sie ein Problem mit der Datenbank als wahrscheinlicher Ursache – nicht sechs einzelne Alerts.

Deployments, Feature-Flag-Änderungen und Konfigurations-Events sind Teil desselben Modells. Eine Anomalie, die zwei Minuten nach einem Release beginnt, wird mit diesem Release verknüpft. Anschließend kann eine agentische Untersuchung laufen: Sie fragt relevante Traces, Logs und Metriken ab, prüft Hypothesen und liefert eine Ursache samt Beweiskette. Jede Abfrage können Sie öffnen und selbst nachvollziehen, zum Beispiel:

fetch spans | filter service == "checkout" and duration > 2s | summarize count(), by:{endpoint, version}

Untersuchungen verbrauchen Intelligence-Agent-Credits; Baselining und Erkennung auf Ihren ingestierten Daten sind inklusive.

Die Sensitivität lässt sich pro Service, Metrik oder Umgebung steuern. So können Sie etwa Staging großzügiger behandeln als Produktion oder für einen besonders kritischen Payment-Service schon kleine Abweichungen melden lassen. Problemmeldungen gehen an dieselben Alerting-Kanäle und Workflows wie alle anderen Benachrichtigungen in Obseria.

Best Practices für die Anomalie-Erkennung

1. Mit nutzernahen Signalen beginnen. Priorisieren Sie Endpoint-Latenz, Fehlerrate und zentrale Business-KPIs vor Infrastrukturdetails.
2. Statische Schwellenwerte für harte Grenzen behalten. Volle Festplatten oder ablaufende Zertifikate sind mit festen Regeln besser abgedeckt.
3. Deployment-Events senden. Kontext zu Änderungen verbessert die Korrelation deutlich und verkürzt Untersuchungen.
4. Sensitivität anpassen statt abschalten. Ist ein Service zu laut, senken Sie seine Empfindlichkeit.
5. Probleme routen, nicht Anomalien. Alarmieren Sie bei korrelierten Problemen und nutzen Sie einzelne Anomalien als Kontext in Dashboards.