Observabilität ruht auf drei Säulen — Logs, Metrics und Traces — und das Ziel ist es, die Frage "Was ist falsch und warum" für ein System zu beantworten, das zu groß ist, um es von Hand zu überprüfen. Im großen Maßstab geht es bei der Strategie um Korrelation, Sampling und Kosten.
| Pillar | Beantwortet | Werkzeuge |
|---|
| Metrics | Stimmt etwas nicht? (rates, latency) | Prometheus, Grafana |
| Traces | Wo im Flow? | OpenTelemetry, Jaeger |
| Logs | Was ist genau passiert? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
Die Trace/Correlation ID muss durch Metric-Labels, Log-Zeilen und Spans fließen, damit Sie zwischen ihnen wechseln können.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
Alles zu 100 % zu protokollieren ist nicht tragbar und erstickt das Signal. Stattdessen samplen, strukturieren und auf SLOs alerten.
Mit hunderten von Services können Sie nicht einfach SSH und nachschauen — Observabilität ist der einzige Weg, um Produktionsverhalten zu verstehen.
Die Gewinnerstrategie ist korreliert, gesampelt und SLO-getrieben: Sie bringt echte Probleme schnell ans Licht, ohne Sie bei der Telemetriespeicherung zu ruinieren oder den On-Call-Dienst im Rauschen zu ersticken.