Recently, I struggled to diagnose a performance issue in our production microservices. A single user request traveled through five services, and I had no clear way to see where bottlenecks occurred. This experience led me to implement distributed tracing—a solution I’ll share with you today. Follow along as we explore how Spring Boot, OpenTelemetry, and Jaeger work together to illuminate your system’s inner workings.

Let’s start with core concepts. Distributed tracing tracks requests across service boundaries using unique identifiers. Each operation becomes a “span,” and related spans form a “trace.” When a service calls another, it passes trace context through headers. Have you considered how much visibility you’re losing without this?

We’ll use OpenTelemetry—the open standard for observability—with Jaeger for visualization. Begin by adding these dependencies to your Spring Boot 3.1+ project:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-jaeger</artifactId>
</dependency>

Run your tracing backend with Docker Compose:

services:
  jaeger:
    image: jaegertracing/all-in-one:1.50
    ports:
      - "16686:16686"  # UI
      - "14250:14250"  # gRPC

Configure OpenTelemetry in your application:

@Bean
public OpenTelemetry openTelemetry() {
    return OpenTelemetrySdk.builder()
        .setTracerProvider(
            SdkTracerProvider.builder()
                .addSpanProcessor(
                    BatchSpanProcessor.builder(
                        JaegerGrpcSpanExporter.builder()
                            .setEndpoint("http://localhost:14250")
                            .build()
                    ).build()
                )
                .setResource(Resource.getDefault())
                .build())
        .build();
}

Spring Boot automatically instruments web requests, database calls, and messaging. But what about custom logic? Manually create spans where needed:

@Autowired private Tracer tracer;

public void processOrder(Order order) {
    Span span = tracer.spanBuilder("processOrder")
                     .setAttribute("order.id", order.getId())
                     .startSpan();
    
    try (Scope scope = span.makeCurrent()) {
        // Business logic
        inventoryService.reserveItems(order);
        paymentService.charge(order);
    } finally {
        span.end();
    }
}

For reactive pipelines, propagate context correctly:

public Mono<Order> createOrderReactive(OrderRequest request) {
    return Mono.deferContextual(ctx -> {
        Span span = tracer.spanBuilder("createOrderReactive")
                         .setParent(Context.current().with(ctx))
                         .startSpan();
        
        return orderRepository.save(request.toOrder())
            .doOnSuccess(order -> span.setAttribute("order.id", order.getId()))
            .doFinally(signal -> span.end());
    });
}

In production, tune performance with sampling:

# application.yml
tracing:
  sampling-ratio: 0.1 # Sample 10% of requests

When issues arise, search traces in Jaeger UI by service, operation, or tag. Notice a slow database query? Drill into the span to see exact SQL execution time. Did you know a single slow service call can cascade into system-wide delays?

I’ve found these optimizations crucial:

1. Set batch sizes to balance overhead and data loss
2. Use async exporters to avoid blocking application threads
3. Add custom attributes to spans for better filtering
4. Correlate traces with logs using trace IDs

After implementing tracing, we reduced our mean diagnosis time from hours to minutes. The visual trace waterfall diagram in Jaeger revealed a third-party API call adding 800ms latency—something we’d never have spotted otherwise.

Try this implementation in your next microservice project. What hidden bottlenecks might you discover? Share your experiences in the comments—I’d love to hear how distributed tracing transforms your workflow. If this helped you, consider liking or sharing with your team!