Observability & Performance Tuning
Distributed Tracing with Micrometer Tracing and Zipkin
Tracing requests through microservice boundaries using Span IDs and Trace IDs.
Interview: Distributed systems debugging. Expect questions on tracing propagation header formats, Micrometer Tracing integration, trace vs span concepts, and tail-based sampling.
Introduction
In microservices architectures, single client requests often trigger complex execution flows across multiple services. If an API request fails or slows down, correlating log files across separate systems without trace context is difficult.
**Distributed Tracing** resolves this. **Micrometer Tracing** (which replaces Spring Cloud Sleuth in Spring Boot 3) injects trace identifiers into outbound request headers, allowing tracing backends (such as **Zipkin**) to construct a visual execution timeline.
Why It Matters
Distributed tracing exposes performance bottlenecks (latency hotspots), identifies the root cause of failures, and maps microservice dependencies dynamically.
Core Tracing Concepts
Traces are organized hierarchically:
• Trace ID: A unique identifier shared by every microservice participating in a transaction.
• Span ID: Represents a single unit of work within a specific microservice.
• Context Propagation: The process of injecting and extracting tracing headers (e.g. W3C traceparent) across network boundaries.
Practical Example
To configure Micrometer Tracing in Spring Boot 3, add the OTEL bridge and export telemetry data to Zipkin:
Next, configure your tracing properties in application.properties:
Quick Quiz
Q1: Which parameter remains constant across all microservices involved in a single, end-to-end API call?
A) Span ID
B) Trace ID
C) Client Port
D) Host IP
Answer: B — The Trace ID is generated at the entry point of the request and propagated across all subsequent network hops to correlate the transaction.
Scenario-Based Challenge
Production Scenario:
Your Spring Boot application makes HTTP calls to downstream services using RestTemplate. You notice that the downstream logs show a different Trace ID than the upstream logs, breaking trace continuity. How do you resolve this?
View Solution
To maintain tracing context across RestTemplate calls:
1. **Avoid manual instantiation:** Avoid using new RestTemplate(). This creates a raw client that lacks Micrometer tracing interceptors.
2. **Inject RestTemplateBuilder:** Inject RestTemplateBuilder and configure it to build the RestTemplate bean:
@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder) {
return builder.build(); # Automatically injects tracing headers
}
3. **W3C Header Verification:** Verify that the downstream client is configured to accept and extract W3C headers (e.g. traceparent) from incoming requests.
Interview Questions
1. What is the difference between Spring Cloud Sleuth and Micrometer Tracing?
Spring Cloud Sleuth was the legacy tracing library used in Spring Boot 2.x, designed to bind closely with Brave or Zipkin. Micrometer Tracing replaces Sleuth in Spring Boot 3.x, acting as an abstraction layer that supports both OpenTelemetry (OTel) and Brave tracers.
Production Considerations
Avoid exporting 100% of traces in production. Highly active apps should use a low sampling rate (e.g. probability=0.05 for 5% of requests) to prevent tracing storage overhead from degrading application performance.