Observability: Monitoring, Logging, Tracing, SLO und Alerting

Drei technische Signale

Metriken zeigen Zahlenverläufe, Logs zeigen Ereignisse, Traces zeigen Pfade über Dienste hinweg.

SLO statt Alarmflut

Ein SLO beschreibt messbare Erwartung, etwa 99,9 Prozent erfolgreiche Bestellungen. Alerts sollen Handlungen auslösen, nicht nur nerven.

Golden Signals

Latenz, Traffic, Fehler und Sättigung liefern gute erste Orientierung. Für Infrastruktur kommen Disk, I/O, Netzwerk und Kapazitätsreserven hinzu.

Betriebsnachweis

Dashboards, Runbooks, Incident-Reports und Postmortems machen Betrieb lernfähig.

Ausführliche Beispiele

SLO Beschreibung

⧉slo:
  service: order-api
  objective: "99.9% erfolgreiche Checkout Requests pro 30 Tage"
  sli:
    good_events: "http_requests{route='/checkout',status!~'5..'}"
    total_events: "http_requests{route='/checkout'}"
  alerting:
    fast_burn: "kritisch, wenn Error Budget in 2h stark verbrennt"
    slow_burn: "Warnung, wenn Trend über 24h schlecht ist"

Prometheus-artige Alert-Regel

⧉groups:
  - name: order-api.rules
    rules:
      - alert: OrderApiHighErrorRate
        expr: rate(http_server_requests_seconds_count{app="order-api",status=~"5.."}[5m]) > 0.05
        for: 10m
        labels:
          severity: critical
          service: order-api
        annotations:
          summary: "Order API Fehlerquote zu hoch"
          runbook: "runbooks/order-api-not-reachable.md"

Prüf- und Verständnis-Checkliste

• SLOs sind mit Fachlichkeit verbunden.
• Alerts haben Owner und Runbook.
• Logs, Metriken und Traces sind korrelierbar.

Merksatz

Enterprise-Regel: Eine Infrastrukturkomponente ist erst fertig, wenn sie fachlich begründet, automatisiert, beobachtet, geschützt, dokumentiert und wiederherstellbar ist.