Observability
In verteilten Systemen ist Observability kein Add-on.
Sie ist eine Voraussetzung für Betriebsfähigkeit.
Ohne Observability sind Microservices:
- schwer debugbar
- operativ fragil
- organisatorisch riskant
Observability ersetzt das „in einem Prozess debuggen“ durch systematische Transparenz.
Ziel
Fehlerlokalisierung über Service-Grenzen hinweg in Minuten statt Stunden.
Nicht nur:
- „Ist das System down?“
Sondern:
- Wo entsteht Latenz?
- Welche Abhängigkeit ist saturiert?
- Welcher Service verursacht Retries?
- Welche Events hängen fest?
Die drei Säulen
1️⃣ Logs
- strukturiert (kein Freitext)
- maschinenlesbar
- mit Correlation ID
- mit eindeutiger Event/Request-ID
Logs beantworten:
Was ist passiert?
2️⃣ Metriken
Pro Service mindestens:
- Latency
- Traffic
- Errors
- Saturation (CPU/Queue/Thread-Pool)
Das entspricht den Golden Signals.
Metriken beantworten:
Wie gesund ist das System?
3️⃣ Distributed Tracing
- Durchgängige Correlation ID
- Trace über Service-Grenzen
- Sichtbarkeit von Call-Chains
- Erkennung von Bottlenecks
Tracing beantwortet:
Wo genau ist das Problem entstanden?