Zum Inhalt

Anomaly Detection

Schwellwerte sind statisch — >80 % CPU = WARN gilt 24/7. Das ignoriert, dass dein Server am Sonntag um 04:00 nie über 5 % geht und unter der Woche um 14:00 normal bei 70 % liegt.

Anomaly Detection lernt diese Muster und schlägt Alarm, wenn ein Wert für den aktuellen Zeitslot deutlich abweicht.

Konzept

Pro Service wird eine Baseline berechnet:

  • Beobachtungszeitraum: 28 Tage
  • Bucket-Größe: 1 Stunde × 7 Tage = 168 Buckets
  • Pro Bucket: Mittelwert + Standardabweichung
flowchart LR
    H[28d Historie] --> B1[Bucket Mo 00:00<br/>μ=12, σ=3]
    H --> B2[Bucket Mo 01:00<br/>μ=10, σ=2]
    H --> Bn[... 168 Buckets]
    LIVE[Live-Wert] --> Z[Z-Score = (x - μ) / σ]
    Bn --> Z
    Z -->|"|z| > Schwelle"| A[Anomaly Event]

Z-Score: wie viele Standardabweichungen weicht der aktuelle Wert vom historischen Mittel des gleichen Wochentag-Stunden-Buckets ab?

Sensitivity Z-Schwelle Wann sinnvoll
Niedrig 4 nur extreme Ausreißer
Mittel 3 Standard, ~99,7 % Konfidenz
Hoch 2 viele Hits, ~95 % Konfidenz

Voraussetzungen

  • Mindestens 7 Tage Daten — vorher gibt es keine sinnvolle Baseline
  • Kontinuierliche Werte — gauge-Typen wie CPU/Memory/Network. Nicht für status (binär) oder info (String).

Baseline-Berechnung

Background-Job läuft täglich um 03:30 UTC und aktualisiert die Baseline für jeden Service:

  1. Letzte 28 Tage Werte holen
  2. Pro Bucket (Wochentag × Stunde) Mittel + Standardabweichung berechnen
  3. In metric_baselines (Migration 040) speichern

Die Baseline rollt also mit — neue Daten kommen rein, alte fallen raus.

Anomaly-Event

Live-Auswertung läuft alle 5 Minuten:

  1. Letzten Wert holen
  2. Aktueller Bucket bestimmen
  3. Z-Score berechnen
  4. Wenn |z| > sensitivity_threshold → anomaly_events-Eintrag

Anomaly-Events erscheinen:

  • Auf der Host-Detail-Seite in der Anomaly-Section
  • Im Dashboard-Widget „Anomaly Events"
  • Als Push, wenn ein dafür konfigurierter Channel existiert

False-Positive-Feedback

Pro Anomaly-Event gibt es einen „Falscher Alarm"-Button. Klick → Event wird als FP markiert, fließt in zukünftige Berechnungen mit reduziertem Gewicht ein.

In der UI sichtbar als kleine Daumen-runter-Icons.

Predictions

Lineare Regression auf 28-Tage-Trend → Vorhersage, wann ein Schwellwert überschritten wird.

Output Bedeutung
predicted_breach_date Datum, an dem der Wert die Krit-Schwelle erreicht (NULL wenn nicht in den nächsten 90 Tagen)
confidence R² der Regression — niedrig = Trend zu volatil, ignoriere
slope_per_day Veränderungsrate

Sichtbar im Dashboard-Widget „Predictions" mit Sortierung nach Dringlichkeit:

🔴 sw-storage-vol1 — 100% Disk in 3 Tagen
🟠 backup01 /var   —  90% Disk in 12 Tagen
🟡 prod-pgsql RAM  —  85% RAM in 30 Tagen

Sinnvoll für Kapazitäts-Planung — du siehst nicht erst, wenn die Disk voll ist, sondern Wochen vorher.

Konfiguration

Host-Detail → Anomaly:

  • Sensitivity pro Service einstellen (Default Mittel)
  • Pause / Resume Anomaly-Detection für einzelne Services
  • Manuelle Re-Baseline triggern (nach größerem Change auf der Maschine)

Was es nicht kann

  • Saisonale Effekte über mehr als 1 Woche — Monatsende-Last, Black-Friday: keine Erkennung. 28d-Window ist zu kurz.
  • Step-Changes — wenn die Last sich grundlegend ändert (Migration auf neuen Dienst), braucht die Baseline 28 Tage zum Lernen. Workaround: manuell Re-Baseline.
  • Multivariate Patterns — „CPU hoch UND Memory hoch UND Disk-IO hoch" wird nicht als kombinierte Anomaly erkannt. Pro Service separat.

Anschluss