TL;DR

Effektives Kubernetes-Alerting mit Prometheus erfordert eine klare Hierarchie aus Critical, Warning und Info. Symptombasierte Alerts statt ursachenbasierter vermeiden Alert Fatigue. Mit PrometheusRule-CRDs und Alertmanager-Routing landen die richtigen Alerts beim richtigen Team — per Slack, PagerDuty oder E-Mail.

Kubernetes Alerting mit Prometheus und Alertmanager

Monitoring ohne Alerting ist wie ein Rauchmelder ohne Batterie. Aber zu viele Alerts sind genauso gefährlich — wenn das Team jede Benachrichtigung ignoriert, gehen echte Probleme unter. Dieses Phänomen heißt Alert Fatigue, und es ist in Kubernetes-Umgebungen weit verbreitet.

Hier ist eine PrometheusRule, die einen Alert bei hoher Pod-Restart-Rate auslöst:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pod-alerts
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: pod.rules
      rules:
        - alert: PodCrashLooping
          expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} ist in CrashLoop"
            description: "Der Pod startet seit 10 Minuten wiederholt neu."

Alert-Hierarchie: Critical, Warning, Info

Nicht jeder Alert verdient einen Pager-Ruf um 3 Uhr nachts. Eine saubere Hierarchie ist die Grundlage für funktionierendes Alerting.

Critical — Sofortige Reaktion nötig. Nutzer sind betroffen oder werden es in Minuten sein. Beispiele: API nicht erreichbar, Cluster-Node down, PersistentVolume voll.

Warning — Handlungsbedarf innerhalb von Stunden. Kein sofortiger Impact, aber Verschlechterung droht. Beispiele: CPU-Throttling, Certificate läuft in 14 Tagen ab, Disk bei 80%.

Info — Zur Kenntnis, kein Handlungsbedarf. Hilfreich für Dashboards und Nachverfolgung. Beispiele: Deployment skaliert, neues Release deployed.

Symptombasiert statt ursachenbasiert

Der häufigste Fehler beim Alerting: Alerts auf Ursachen statt auf Symptome setzen. Ein Alert "CPU bei 90%" sagt nichts darüber aus, ob Nutzer betroffen sind. Manche Workloads laufen absichtlich bei hoher CPU-Last.

Besser: Alert auf die Auswirkung. Wenn die Request-Latenz steigt oder die Error-Rate hochgeht, ist das ein klares Signal.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: latency-alerts
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: latency.rules
      rules:
        - alert: HighRequestLatency
          expr: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{job="api-server"}[5m])) by (le)
            ) > 1.0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "API-Latenz über 1 Sekunde (p99)"
            description: "Das 99. Perzentil der API-Antwortzeit liegt seit 5 Minuten über 1s."
        - alert: HighErrorRate
          expr: |
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m])) > 0.05
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Error-Rate über 5%"
            description: "Mehr als 5% aller HTTP-Requests liefern 5xx-Fehler."

Ursachenbasierte Alerts wie "CPU hoch" oder "Memory steigt" gehören als Warning oder Info — sie helfen beim Debugging, sollten aber niemanden nachts wecken.

Alertmanager-Routing konfigurieren

Der Alertmanager entscheidet, wer welchen Alert bekommt. Die Konfiguration erfolgt über eine Routing-Tree-Struktur mit Receivern.

apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: team-routing
  namespace: monitoring
  labels:
    alertmanagerConfig: main
spec:
  route:
    receiver: slack-warnings
    groupBy: ['alertname', 'namespace']
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 4h
    routes:
      - receiver: pagerduty-critical
        matchers:
          - name: severity
            value: critical
            matchType: "="
        repeatInterval: 5m
      - receiver: slack-warnings
        matchers:
          - name: severity
            value: warning
            matchType: "="
        repeatInterval: 4h
  receivers:
    - name: pagerduty-critical
      pagerdutyConfigs:
        - routingKey:
            name: pagerduty-secret
            key: routing-key
          severity: critical
          description: '{{ .CommonAnnotations.summary }}'
    - name: slack-warnings
      slackConfigs:
        - apiURL:
            name: slack-webhook-secret
            key: url
          channel: '#k8s-alerts'
          title: '[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}'
          text: '{{ .CommonAnnotations.description }}'
          sendResolved: true

Grouping und Inhibition

Zwei Mechanismen verhindern Alert-Spam:

Grouping fasst zusammengehörige Alerts zusammen. Wenn 20 Pods gleichzeitig crashen, kommt eine Nachricht statt 20. Die Parameter groupBy, groupWait und groupInterval steuern das Verhalten.

Inhibition unterdrückt nachgelagerte Alerts. Wenn ein Node down ist, müssen die Pod-Alerts auf diesem Node nicht extra gemeldet werden:

inhibitRules:
  - sourceMatch:
      - name: alertname
        value: NodeDown
        matchType: "="
    targetMatch:
      - name: severity
        value: warning
        matchType: "="
    equal: ['node']

Alert Fatigue vermeiden

Alert Fatigue ist messbar: Wenn dein Team mehr als 50% der Alerts ohne Aktion schließt, hast du ein Problem. Hier sind die wichtigsten Gegenmaßnahmen.

Ein praktischer Ansatz: Führe ein monatliches Alert-Review ein. Jeder Alert, der im letzten Monat keine Aktion ausgelöst hat, wird entweder angepasst oder gelöscht. Alerts sind Code — sie verdienen denselben Review-Prozess wie Anwendungscode.

Praxistipps für PrometheusRule-CRDs

Beim Einsatz des kube-prometheus-stack werden Alert-Regeln als PrometheusRule Custom Resources verwaltet. Einige Hinweise:

• Das Label release: kube-prometheus-stack muss gesetzt sein, damit der Prometheus Operator die Regeln erkennt
• Teste Expressions vorher in der Prometheus-UI unter /graph
• Nutze for-Werte von mindestens 5 Minuten für alles außer absolut kritische Alerts
• Halte Annotations konsistent: immer summary und description

# Alle PrometheusRules im Cluster auflisten
kubectl get prometheusrules --all-namespaces

# Alert-Regeln eines spezifischen Rules-Set prüfen
kubectl describe prometheusrule pod-alerts -n monitoring

FAQ

Wie viele Alerts sollte ein Team pro Tag maximal bekommen?

Ein gut konfiguriertes Alerting erzeugt nicht mehr als 5-10 actionable Alerts pro Schicht. Alles darüber führt zu Desensibilisierung. Critical-Alerts sollten seltener als einmal pro Tag auftreten.

Was ist der Unterschied zwischen Prometheus-Alerting und Alertmanager?

Prometheus evaluiert die Alert-Regeln und erkennt, ob ein Alert aktiv ist. Der Alertmanager übernimmt das Routing, Grouping, Silencing und die Zustellung an Empfänger wie Slack oder PagerDuty. Beide Komponenten arbeiten zusammen.

Kann ich Alerts temporär stumm schalten?

Ja, der Alertmanager bietet Silences. Über die Web-UI oder die API kannst du Alerts für einen definierten Zeitraum unterdrücken — zum Beispiel während geplanter Wartungsarbeiten. Silences sollten immer ein Ablaufdatum haben.

Wie teste ich Alert-Regeln vor dem Deployment?

Nutze promtool aus dem Prometheus-Paket. Mit promtool check rules rules.yaml validierst du die Syntax. Unit-Tests für Alert-Regeln sind ebenfalls möglich mit promtool test rules.

Nächster Schritt: Kombiniere dein Alerting mit einem vollständigen Observability-Stack. Mit OpenTelemetry auf Kubernetes bekommst du neben Metriken auch Traces und Logs in einer einheitlichen Pipeline.