Verteiltes Tracing & Observability
Verfolge eine Anfrage über viele Dienste hinweg mit Trace-IDs, mittels Micrometer Tracing und OpenTelemetry.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
In a monolith, one request is one thread, and its logs sit together. In a microservice system, a single user action might touch the gateway, lending, catalog, and notification services - four sets of logs on four machines. When something is slow or broken, which service? and how do you connect the pieces? Distributed tracing stitches them into one story.
One trace ID, all the way through
The idea: when a request enters the system, it's tagged with a unique trace ID. Every service it touches propagates that ID and adds its own span (a timed unit of work). Now you can filter every log and timing across all services by that one trace ID and see the whole journey.
In Spring, Micrometer Tracing (with OpenTelemetry or Zipkin) does this automatically: it generates and propagates trace/span IDs across service calls, and adds them to your logs:
[lending-service] [traceId=a1b2c3 spanId=d4e5] Borrowing book 978-...
[catalog-service] [traceId=a1b2c3 spanId=f6a7] Fetching book 978-...Same traceId - two services, one request. A tracing UI (Zipkin, Grafana Tempo) then shows a
waterfall of spans, so you see exactly where the time went.
A parcel crossing several depots and couriers would be impossible to follow if each handler used its own reference. Instead it gets one tracking number that every depot scans, so you can pull up its entire journey - each hop, each delay - end to end. A trace ID is that tracking number for a request: every service scans it, and you can reconstruct the request's whole path across the system.
Tracing complements logs and metrics
The three pillars of observability work together: metrics tell you something is wrong (latency is up), traces tell you where (which service/hop), and logs tell you what (the error detail). Correlating logs by trace ID is what makes a distributed system debuggable.
A BookVault borrow request is intermittently slow, passing through gateway → lending → catalog. The logs on each service look fine individually. Explain how distributed tracing lets you pin down which hop is slow, when per-service logs alone can't.
Why is distributed tracing essential in a microservices system?
Key takeaways
- Distributed tracing tags each request with a unique trace ID that every service propagates, tying the whole flow together.
- Each service adds a timed span; a tracing UI shows a waterfall revealing where time is spent.
- Micrometer Tracing (with OpenTelemetry/Zipkin) generates and propagates IDs and injects them into logs automatically.
- Correlating logs by trace ID is what makes a multi-service request debuggable.
- Traces (where), metrics (that something's wrong), and logs (what) together form observability.