Distributed Tracing with Micrometer Tracing (Spring Boot 3)

Distributed tracing solves the problem of debugging requests that span multiple services. When an order fails in production, you need to know exactly where it failed — the gateway, the order service, the inventory check, or the payment call. Without tracing, you're correlating five log files by timestamp and hoping server clocks are synchronized.

How it works:

• A trace ID is assigned at the entry point and propagated in W3C traceparent headers to every downstream call; each service generates a span ID for its work, with parent-child relationships building a flame graph
• In Spring Boot 3, Micrometer Tracing handles propagation automatically through RestTemplate, WebClient, and Spring Data without code changes; add the log pattern %X{traceId} to correlate logs across services with a single search

The async boundary gotcha:

• When the order service publishes to Kafka, the consumer loses trace context because there's no HTTP header to extract from the message
• You must explicitly inject the trace context into Kafka record headers at publish time, and extract it in the consumer; without this, the consumer's trace appears orphaned with no connection to the originating request

Sampling strategy:

• Never sample at 100% — at 10K RPS across 5 services, that's 50GB of trace data per day in Zipkin or Jaeger
• Use 5–10% probability sampling with error-biased override so failures are always captured regardless of the sampling rate; log correlation with %X{traceId} still works on unsampled requests

I recommend wiring Micrometer Tracing from day one — retrofitting trace propagation through async boundaries is significantly harder than getting it right at service creation time.