Wie wählen Sie Alert-Schwellenwerte aus, um Alert-Fatigue und falsch-positive Ergebnisse zu vermeiden?

Question

Accepted Answer

Die Grundregel: **Warnen Sie vor Symptomen, nicht vor Ursachen**, und **benachrichtigen Sie nur, wenn es umsetzbar und dringend ist**. Ein lauter Alert, der jede Nacht ausgelöst wird, wird stummgeschaltet oder ignoriert — also ist das eigentliche Risiko nicht ein verpasster Alert, sondern ein desensibilisierter On-Call, der durch den echten schläft.

## Symptome statt Ursachen

Warnen Sie vor **benutzerorientierten SLOs** (Fehlerquote, Latenz, Verfügbarkeit), nicht vor internen Ursachen wie "CPU > 80%". Hohe CPU kann harmlos sein; was zählt, ist, ob Benutzer betroffen sind.

```text
BAD  (cause)     CPU > 80% for 5m            → fires constantly, often no impact
GOOD (symptom)   error-rate SLO burn is fast → fires only when users hurt
```

## Multi-Window Burn-Rate Alerts

Ein einzelner statischer Schwellenwert ist entweder zu empfindlich oder zu langsam. Warnen Sie stattdessen, wie schnell Sie Ihr **Error Budget** aufbrauchen, indem Sie zwei Fenster verwenden, sodass ein schneller Burn sofort benachrichtigt und ein langsamer Burn nur bei Dauerhaftigkeit benachrichtigt.

```yaml
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # fast window: catch big outages
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # short window: confirm it's still happening
  for: 2m
  labels: { severity: page }
```

Das kurze Fenster verhindert eine Benachrichtigung für ein bereits selbstgelöstes Problem; das lange Fenster verhindert eine Benachrichtigung bei einem kurzen Zuckung.

## Benachrichtigung vs. Ticket vs. Dashboard

```text
PAGE       actionable + urgent  → wake a human now (SLO at risk, checkout down)
TICKET     actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD  informational         → no alert, just visible (per-endpoint traffic)
```

Wenn ein Alert nicht umsetzbar ist, sollte er nicht benachrichtigen — wandeln Sie ihn in ein Ticket oder ein Dashboard-Panel um. Dann **stimmen Sie im Laufe der Zeit ab**: Überprüfen Sie jede Benachrichtigung, löschen Sie diejenigen, auf die niemand reagiert hat.

## Warum es wichtig ist

Alert-Fatigue ist ein Zuverlässigkeitsrisiko, nicht nur eine Unannehmlichkeit: Menschen filtern unbewusst laute Kanäle, also je mehr falsch-positive Ergebnisse Sie senden, desto wahrscheinlicher wird ein echter Ausfall übersehen. Durch Warnungen vor Symptomen mit Burn-Rate-Fenstern und die Beschränkung von Benachrichtigungen auf umsetzbare Dringlichkeit bleibt jede Benachrichtigung sinnvoll — das ist es, was den On-Call reaktionsfähig hält.