I’ve been thinking about how modern applications have become intricate webs of microservices. Each request now travels through multiple services, databases, and external APIs. When something goes wrong, finding the root cause can feel like detective work without clues. That’s why I decided to explore distributed tracing—it gives us the visibility we desperately need in complex systems.

Let me show you how to implement distributed tracing in Spring Boot applications using OpenTelemetry and Jaeger. This approach provides a complete picture of how requests move through your system, making debugging and performance optimization much more straightforward.

First, we need to set up our environment. I prefer using Docker Compose to run Jaeger because it keeps things simple and reproducible. Here’s a basic setup:

version: '3.8'
services:
  jaeger:
    image: jaegertracing/all-in-one:1.50
    ports:
      - "16686:16686"
      - "4317:4317"

Run this with docker-compose up, and you’ll have Jaeger ready to receive traces. The UI will be available at http://localhost:16686.

Now, let’s configure our Spring Boot application. Add these dependencies to your pom.xml:

<dependency>
    <groupId>io.opentelemetry.instrumentation</groupId>
    <artifactId>opentelemetry-spring-boot-starter</artifactId>
    <version>2.0.0</version>
</dependency>

Have you ever wondered how automatic instrumentation actually works? OpenTelemetry uses Java agents and auto-configuration to instrument common frameworks like Spring Web, JDBC, and WebClient without much manual intervention.

Configure your application.yaml with basic settings:

management:
  tracing:
    sampling:
      probability: 1.0
opentelemetry:
  service:
    name: order-service
  exporter:
    otlp:
      endpoint: http://localhost:4317

This configuration tells OpenTelemetry to send all traces to our local Jaeger instance. The sampling rate of 1.0 means we’re capturing every request—perfect for development, though you might want to adjust this in production.

Now, let’s create a simple service to see tracing in action:

@Service
public class OrderService {
    
    @Autowired
    private WebClient webClient;
    
    public Mono<Order> createOrder(OrderRequest request) {
        return webClient.post()
            .uri("/inventory/check")
            .bodyValue(request)
            .retrieve()
            .bodyToMono(InventoryResponse.class)
            .flatMap(response -> processOrder(request, response));
    }
}

Notice how we’re making external HTTP calls? OpenTelemetry automatically instruments WebClient to propagate trace context. This means when our service calls the inventory service, the trace continues seamlessly.

What happens when we need custom instrumentation? Sometimes automatic tracing isn’t enough. Let me show you how to add custom spans:

@Autowired
private Tracer tracer;

public void processOrder(OrderRequest request) {
    Span customSpan = tracer.spanBuilder("order-processing")
        .setAttribute("order.id", request.getId())
        .startSpan();
    
    try (Scope scope = customSpan.makeCurrent()) {
        // Your business logic here
        validateOrder(request);
        calculateTotal(request);
    } finally {
        customSpan.end();
    }
}

This custom span gives us more detailed information about specific operations within our service. We can add attributes, events, and even status codes to make our traces more meaningful.

Database operations are automatically traced too. When using Spring Data JPA, OpenTelemetry instruments your repository calls:

public interface OrderRepository extends JpaRepository<Order, Long> {
    @Query("SELECT o FROM Order o WHERE o.status = :status")
    List<Order> findByStatus(@Param("status") String status);
}

Each database query will appear as a separate span in your trace, showing execution time and any potential errors.

Error handling becomes much easier with distributed tracing. When an exception occurs, OpenTelemetry automatically captures it and marks the span as errored:

public void riskyOperation() {
    Span span = tracer.spanBuilder("risky-operation").startSpan();
    try (Scope scope = span.makeCurrent()) {
        // Code that might throw an exception
        throw new RuntimeException("Something went wrong");
    } catch (Exception e) {
        span.recordException(e);
        span.setStatus(StatusCode.ERROR);
        throw e;
    } finally {
        span.end();
    }
}

This approach ensures that errors are properly recorded and visible in your traces, making debugging much more straightforward.

As your application grows, you might want to optimize tracing performance. Consider using probabilistic sampling in production:

management:
  tracing:
    sampling:
      probability: 0.1

This samples only 10% of requests, reducing the overhead while still providing valuable insights. But how do you know which sampling rate is right for your application? It depends on your traffic volume and observability needs.

I’ve found that implementing distributed tracing fundamentally changes how we understand our systems. It’s not just about debugging—it’s about gaining deep insight into how your application actually behaves in production.

The beauty of this setup is that it works across multiple services. Whether you have two microservices or two hundred, the tracing context propagates automatically through HTTP headers, giving you a complete view of request flows.

Now that you’ve seen how to implement distributed tracing, I encourage you to try it in your own projects. Start with a simple service and gradually add more instrumentation. The visibility you’ll gain is invaluable for maintaining complex systems.

If you found this helpful, please share it with your team or colleagues who might benefit from better observability. I’d love to hear about your experiences with distributed tracing—what challenges have you faced, and what insights have you gained? Leave a comment below and let’s continue the conversation.