Great question! Let’s break this down into two clear parts: implementing trace tracking for raw kafka-clients using Spring Cloud Sleuth, and weighing whether Sleuth is the right choice vs. manual trace ID passing.

一、Implementing Spring Cloud Sleuth with Kafka Clients #

Spring Cloud Sleuth does support native Kafka producers/consumers—you just need to wire up its interceptors to inject and extract trace metadata from Kafka message headers. Here’s a step-by-step setup:

1. Add Dependencies #

First, ensure you have the required Sleuth starter in your pom.xml (or build.gradle):

<!-- Maven -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
    <!-- Match your Spring Cloud version, e.g., 3.2.5 for 2022.0.x release train -->
</dependency>

This includes the instrumentation libraries needed for Kafka client integration.

2. Configure Kafka Producer with Sleuth Interceptor #

Add Sleuth’s TracingProducerInterceptor to your producer config to automatically inject trace IDs (in B3 format, e.g., X-B3-TraceId, X-B3-SpanId) into message headers:

@Bean
public ProducerFactory<String, MyEvent> kafkaProducerFactory() {
    Map<String, Object> config = new HashMap<>();
    config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
    config.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
    config.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, JsonSerializer.class);
    // Attach Sleuth's producer interceptor
    config.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG, 
        TracingProducerInterceptor.class.getName());
    return new DefaultKafkaProducerFactory<>(config);
}

When you send messages via this producer, Sleuth will pull the current trace context from your application thread and attach it to the Kafka message headers.

3. Configure Kafka Consumer with Sleuth Interceptor #

For consumers, use TracingConsumerInterceptor to extract trace metadata from incoming messages and continue the trace chain:

@Bean
public ConsumerFactory<String, MyEvent> kafkaConsumerFactory() {
    Map<String, Object> config = new HashMap<>();
    config.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
    config.put(ConsumerConfig.GROUP_ID_CONFIG, "event-processing-group");
    config.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
    config.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, JsonDeserializer.class);
    // Attach Sleuth's consumer interceptor
    config.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG, 
        TracingConsumerInterceptor.class.getName());
    return new DefaultKafkaConsumerFactory<>(config);
}

If you’re using manual consumer instantiation (not Spring’s @KafkaListener), just add the interceptor class name to your consumer config map directly—same principle applies.

4. Verify the Trace Chain #

Once set up, you’ll see consistent trace IDs across your producer service logs, Kafka message headers, and consumer service logs. If you use a tool like Zipkin, you’ll get a full visual of the flow: REST API -> Producer -> Kafka -> Consumer.

二、Spring Cloud Sleuth vs. Manual Trace ID Handling: Which is Better? #

Let’s compare the two approaches based on real-world use cases:

Why Choose Spring Cloud Sleuth? #

• Out-of-the-box integration: No need to write custom code for trace ID generation, header injection/extraction, or context management. Sleuth handles all of this, including thread-local context propagation for async tasks (like Kafka consumer threads).
• Full ecosystem support: Beyond Kafka, Sleuth automatically traces REST endpoints, Feign clients, RabbitMQ, Redis, and more. If your system uses multiple distributed components, this gives you a unified trace view without extra work.
• Standardization: Sleuth uses industry-standard formats (B3, W3C Trace Context) which are compatible with tools like Zipkin, Jaeger, and OpenTelemetry. This avoids lock-in to custom trace formats.
• Reduced maintenance: Manual implementations often suffer from edge cases (e.g., async context loss, inconsistent header names) that Sleuth has already solved.

When to Consider Manual Trace ID Passing? #

• Tiny, isolated systems: If you only have a simple producer/consumer pair with no other distributed components, manual passing might be lighter (no Sleuth dependency).
• Custom requirements: If your team enforces a non-standard trace format or header structure that Sleuth can’t easily adapt to, manual code gives you full control.
• Non-Spring Cloud environments: If your project isn’t part of the Spring Cloud ecosystem, Sleuth might be overkill, and manual passing is the only option.

Final Recommendation #

If you’re working within a Spring Cloud ecosystem (or plan to expand to other distributed components), Spring Cloud Sleuth (or its successor, Spring Cloud OpenTelemetry) is the clear winner. It eliminates repetitive code, ensures trace consistency, and integrates seamlessly with modern observability tools. Manual trace ID passing is only justified for very simple, isolated use cases.

内容的提问来源于stack exchange，提问作者Kailas Andhale