Distributed Tracing with Spring Cloud Sleuth and Zipkin/Jaeger
Fast recall
Quick revision
Core answer
Understanding of trace propagation, span context, and the difference between Sleuth and OpenTelemetry-based tracing.
Not setting `spring.sleuth.sampler.probability` in production, resulting in 100% trace sampling that overwhelms the backend.
Explain the move from Sleuth to Micrometer Tracing in Spring Boot 3 and why OpenTelemetry is now the preferred standard.
Interview-ready guide
Interview answer
Distributed tracing assigns a unique trace ID to each incoming request and propagates it across every service and database call — which means you can see the full timeline of one request and pinpoint exactly where latency comes from.
How tracing works
- When a request arrives at the first service, the tracing library (Sleuth or Micrometer Tracing) generates a trace ID and a span ID; subsequent outbound calls to other services include the trace ID in HTTP headers (
traceparentin W3C format, orX-B3-TraceIdin Zipkin B3 format) - Each service that processes the request creates its own span — a timed unit of work within the trace; a span records start time, end time, service name, and tags (HTTP status, database query, error message)
- Spans are reported asynchronously to a collector (Jaeger, Zipkin, or OpenTelemetry Collector) and correlated by trace ID to reconstruct the full tree
Spring Boot setup
- Spring Boot 2: add
spring-cloud-starter-sleuthandspring-cloud-sleuth-zipkin; Sleuth auto-instruments HTTP, Spring Kafka, and Spring Data calls; configurespring.zipkin.base-urlfor the collector - Spring Boot 3: Sleuth is replaced by
micrometer-tracing-bridge-otel(OpenTelemetry) ormicrometer-tracing-bridge-brave(Zipkin/Jaeger); configure an exporter for the collector backend
What gets auto-instrumented
- Every inbound HTTP request and outbound
RestTemplate,WebClient, orFeignClientcall - Spring Kafka consumer and producer operations — the trace ID is embedded in Kafka message headers
- Spring Data repositories — database queries appear as spans under the HTTP request span, showing exactly how much of the request time was spent in the database
Reading traces in Jaeger/Zipkin
- A trace with one HTTP request span and three database spans shows the service spent 450ms in three sequential queries — the bottleneck is clear without reading logs
- Filter by
http.urlorerror=trueto find all failing traces for a specific endpoint across all service instances
Distributed Tracing with Spring Cloud Sleuth and Zipkin/Jaeger
Direct Answer
Add Spring Cloud Sleuth (or Micrometer Tracing in Boot 3) to auto-instrument HTTP, messaging, and database calls. Configure an exporter to send spans to Zipkin or Jaeger. Trace and span IDs are automatically propagated in HTTP headers.
Common Mistakes & Pitfalls
Not setting spring.sleuth.sampler.probability in production, resulting in 100% trace sampling that overwhelms the backend.
Check your understanding
Answer these without looking back at the article.
- What is the difference between a trace ID and a span ID?
- How does B3 propagation differ from W3C Trace Context?
- What sampling strategy would you use in a high-throughput service?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.