Observability Deep Dive: OpenTelemetry & Betrieb
Logs, Metrics, Traces, Baggage, Sampling, SLOs, Dashboards und fachliche Nachvollziehbarkeit.
Version 2BetriebCodeDiagramm
In dieser Datei
Drei Signale verbinden
Logs erklären Details, Metriken zeigen Verhalten über Zeit, Traces verbinden Aufrufe über Systemgrenzen. Gute Observability macht fachliche Vorgänge sichtbar.
Trace-Kontext durchreichen
TraceId und fachliche IDs wie orderId oder customerId müssen über HTTP, Messaging und Batch hinweg nachvollziehbar bleiben. Dabei dürfen sensible Daten nicht unkontrolliert in Logs landen.
SLO statt Dashboard-Sammlung
Dashboards sind nur hilfreich, wenn klar ist, welche Service-Level-Ziele gelten: Latenz, Fehlerrate, Verfügbarkeit, Queue Lag, Durchsatz.
Entscheidungen
| Entscheidung | Gute Praxis | Prüffrage |
|---|---|---|
| Fachliche Grenze | Zuerst Use Case, Invariante und Verantwortlichkeit klären. | Welche Geschäftsentscheidung wird geschützt? |
| Technische Grenze | Framework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln. | Kann die Domain ohne Framework getestet werden? |
| Betrieb | Timeouts, Logs, Metriken, Traces, Security und Rollback definieren. | Wie erkennt der Betrieb Fehler rechtzeitig? |
Ausführliche Beispiele
OpenTelemetry Attribute
Span span = Span.current();
span.setAttribute("business.operation", "place-order");
span.setAttribute("order.id", order.id().value().toString());
span.setAttribute("customer.id", order.customerId().value());
Strukturiertes Logging
log.info("order_placed order={} customer={} total={} traceId={}",
order.id().value(), order.customerId().value(), order.total(), MDC.get("traceId"));
Typische Stolperfallen
| Stolperfalle | Warum gefährlich |
|---|---|
| PII in Logs | Datenschutz und Security werden verletzt. |
| Nur technische Metriken | Fachlicher Zustand bleibt unsichtbar. |
| Sampling ohne Regeln | Fehlerhafte oder langsame Requests fehlen im Trace-System. |