Spring Cloud Sleuth集成OpenZipkin问题：GUI未显示全部Span

Hey there! Let’s break down what’s happening here and figure out why you’re only seeing UppercaseApp spans in the Zipkin GUI even though the downloaded JSON includes ReverseApp ones.

First, great catch checking the raw JSON—this tells us the tracing data is actually making it to Zipkin, so the problem isn’t with data collection or sending. The issue is likely with how Zipkin’s GUI is displaying the trace, or a small configuration gap in how your services are linking spans across the message broker.

Let’s Diagnose the Span Linking Issue #

Looking at your JSON data, notice the first ReverseApp consumer span has a parentId: "8432f0d20ee1c58a"—but there’s no span in the list with that ID. The last span from UppercaseApp is a producer span with id: "b136a2d5e017b1c6", which should be the parent of the ReverseApp consumer span. This mismatch means Sleuth isn’t correctly passing the parent span ID from the producer to the consumer via message headers.

Why This Happens & Fixes to Try #

1. Verify Sleuth & Stream Compatibility
   Make sure your Spring Cloud Sleuth and Spring Cloud Stream versions are compatible with each other (and your overall Spring Boot version). Mismatched versions can break automatic header propagation of trace context.

2. Check Trace Header Propagation
   Sleuth should automatically inject X-B3-TraceId, X-B3-SpanId, and X-B3-ParentSpanId headers into messages sent via Stream. Double-check:

   • Both services have the spring-cloud-starter-sleuth and spring-cloud-starter-stream-<your-broker> dependencies (e.g., kafka/rabbitmq).
   • You haven’t customized message header filters in your Stream bindings that might remove these trace headers. Some brokers (like Kafka) have default header restrictions, so ensure your broker configuration allows these headers to pass through.

3. Adjust Zipkin GUI Viewing Settings
   Even if spans aren’t perfectly linked by parent ID, they share the same traceId: "ff03e5a7078c7300", so they should appear in the same trace view. Try:

   • Searching directly for the trace ID in Zipkin’s search bar—this should pull up all 6 spans.
   • Using the Dependency Graph view to see if both uppercaseapp and reverseapp appear (this view aggregates spans by service regardless of parent links).
   • Expanding all spans in the trace detail view—sometimes child spans are collapsed by default, especially if the parent link is broken.

Quick Test to Confirm #

Search for serviceName:reverseapp in Zipkin—you should see the ReverseApp spans pop up. Click on one to open the trace, and you’ll see all spans in the same trace (even if they’re displayed as separate branches instead of nested). This confirms the data is there, and the fix is just getting the parent span ID to propagate correctly.

Once you fix the header propagation, the Zipkin GUI will display the full nested trace flow you expect: UppercaseApp → broker → ReverseApp.

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