I’ve been building microservices for years, and there’s one problem that always resurfaces: tracking a single request as it jumps between services. It feels like trying to follow a conversation in a crowded room where everyone is talking at once. This frustration led me to explore distributed tracing, and I want to share how OpenTelemetry and Jaeger can bring clarity to your Spring Boot applications.

Have you ever spent hours debugging an issue, only to realize the problem occurred in a service you didn’t even consider? Distributed tracing solves this by painting a complete picture of request journeys. It shows you exactly where time is spent and where errors originate across your entire system.

Let’s start with the foundation. You’ll need a way to collect and visualize traces. Jaeger provides a straightforward solution. I run it locally using Docker Compose, which sets up everything in minutes. Here’s a basic setup that includes Jaeger and some supporting services:

services:
  jaeger:
    image: jaegertracing/all-in-one:1.50
    ports:
      - "16686:16686"
    environment:
      - COLLECTOR_OTLP_ENABLED=true

With the infrastructure ready, the next step is instrumenting your Spring Boot services. OpenTelemetry acts as the universal standard for this. I add the necessary dependencies to my pom.xml file. The spring-boot-starter and OTLP exporter are essential for automatic instrumentation.

What happens when a service communicates with a database or another service? OpenTelemetry captures these interactions automatically. But sometimes, you need more control. That’s where manual instrumentation comes in. Let me show you how I add custom spans to track specific business logic.

@Autowired
private Tracer tracer;

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

Configuration is crucial for making everything work together. I use application.yml to define how traces are exported to Jaeger. Setting the service name and endpoint ensures that traces from different services can be correlated properly. The sampling rate helps control the volume of data collected, especially important in production.

How do you ensure that trace context is propagated between services? OpenTelemetry handles this automatically for HTTP calls through context propagation. When one service calls another, the trace ID and span ID are passed in headers, maintaining the chain across service boundaries.

Here’s a practical example from an order service. When creating an order, it might call inventory and payment services. With distributed tracing, you can see the entire flow in Jaeger’s UI. Each service adds its own spans, creating a timeline of the request’s path.

@RestController
public class OrderController {
    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody Order order) {
        // This will automatically be traced
        Order savedOrder = orderService.save(order);
        return ResponseEntity.ok(savedOrder);
    }
}

Logging becomes much more powerful when correlated with traces. I configure my logging pattern to include trace and span IDs. This way, when I see an error in the logs, I can immediately jump to the exact trace in Jaeger to see the full context.

What about asynchronous processing? If you’re using message queues, you need to manually propagate the trace context. I extract the context from the current span and inject it into message headers before sending. The receiving service then extracts it to continue the trace.

// Sending a message
Span currentSpan = Span.current();
TextMapSetter<Message> setter = (message, key, value) -> 
    message.getProperties().put(key, value);
tracer.propagate(currentSpan.getSpanContext(), message, setter);
rabbitTemplate.convertAndSend("exchange", "routingKey", message);

In production, you’ll want to adjust the sampling rate. Collecting 100% of traces can be expensive. I typically start with a high rate in development and lower it in production based on traffic and storage costs. OpenTelemetry’s ratio-based sampler makes this easy to configure.

The real value comes when you start adding custom attributes to spans. I include business-specific data like user IDs, order amounts, or product categories. This turns tracing from a debugging tool into a business monitoring solution. You can analyze which user segments experience the slowest responses or highest error rates.

Have you considered how tracing impacts performance? The overhead is minimal, especially with async exporters. OpenTelemetry batches spans and sends them in the background. In my experience, the insights gained far outweigh any performance cost.

Implementing distributed tracing transformed how my team handles incidents. We can now pinpoint issues in minutes instead of hours. The visual representation in Jaeger makes complex interactions understandable to everyone, from developers to product managers.

I encourage you to start small—add tracing to one service and see the immediate benefits. Once you experience the clarity it brings, you’ll want it everywhere. If this approach resonates with you, I’d love to hear about your experiences. Please share your thoughts in the comments, and if you found this helpful, consider liking and sharing it with others who might benefit.