Alerting richtig aufsetzen
Monitoring ohne Alerting ist wie ein Rauchmelder ohne Alarm — man sieht den Brand in Grafana, aber nur wenn man gerade draufschaut.
Was alarmiert werden sollte
Nicht jede Anomalie braucht einen Alert. Zu viele Alerts führen zu Alert-Fatigue — man gewöhnt sich dran und ignoriert sie.
- Gute Alerts:
- Fehlerrate über einem Schwellwert für mehr als X Minuten
- Service nicht erreichbar
- Disk voll in weniger als 4 Stunden (Trend-basiert)
- Datenbankverbindungen nahe am Maximum
- Schlechte Alerts:
- CPU kurz über 80% (spikes sind normal)
- Einzelner HTTP-Fehler
- Metrik die man interessant findet aber nicht actionable ist
Prometheus Alertmanager
# alert-rules.yml
groups:
- name: app
rules:
- alert: HighErrorRate
expr: rate(http_errors_total[5m]) / rate(http_requests_total[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Fehlerrate über 5%"
description: "Aktuelle Rate: {{ $value | humanizePercentage }}"
- alert: DiskWillFillIn4h
expr: predict_linear(node_filesystem_free_bytes[1h], 4*3600) < 0
for: 5m
labels:
severity: warning
Alertmanager-Konfiguration
# alertmanager.yml
route:
receiver: telegram
receivers:
- name: telegram
telegram_configs:
- bot_token: '${TELEGRAM_BOT_TOKEN}'
chat_id: -100123456789
message: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'
Eskalation und Stille
route:
group_wait: 30s # Alerts sammeln bevor senden
group_interval: 5m # Wie oft erneut senden wenn aktiv
repeat_interval: 4h # Wie oft wiederholen wenn nicht resolved
routes:
- match:
severity: critical
receiver: pagerduty
- match:
severity: warning
receiver: telegram
Silence für Wartung
# Alert für 2 Stunden stumm schalten amtool silence add alertname="HighErrorRate" --duration=2h --comment="geplante Wartung"
Der wichtigste Grundsatz: jeder Alert muss actionable sein. Wenn man nicht weiß was zu tun ist wenn er kommt gehört er gelöscht oder überarbeitet.