Spring Boot 3.1+B3_MULTI：Micrometer接收请求生成新Span的疑问

问题背景 #

在Spring Boot 3.1项目中配置B3_MULTI追踪传播策略后，观察到以下行为：

• 服务器接收请求时，Micrometer会创建新的Span，日志中记录的是这个新生成的SpanID，而非请求自带的SpanID
• 通过RestTemplate调用其他API时，Micrometer会创建新Span并将其ID放入X-B3-spanID请求头，该行为符合预期

核心困惑：若服务器接收请求后立即记录新SpanID，那么请求中携带的SpanID还有什么作用？

配置与示例信息 #

application.yml配置：

management:
  tracing:
    propagation:
      type: B3_MULTI

Postman请求头：

X-B3-SpanId: 97552541f44c6a8e
X-B3-TraceId: affca7de79bdf483

应用日志片段：

... affca7de79bdf483 | 5631f587ff130771 ...

其中5631f587ff130771是当前服务生成的新SpanID。

核心原理与解答 #

1. 为什么接收请求会生成新SpanID？ #

这是分布式追踪的标准行为：请求携带的X-B3-SpanId是上游服务的父SpanID，当前服务器接收到请求后，会创建一个独立的子Span来处理本次请求，这个子Span必然拥有自己的唯一SpanID。

这种设计是为了精准区分每个服务节点对请求的处理过程，让链路追踪能清晰展示请求在各个服务间的流转步骤。

2. 请求自带SpanID的作用 #

请求中的X-B3-SpanId（上游父SpanID）的核心价值是建立父子Span的关联关系：

• 追踪框架会自动将当前服务的新Span与上游的父Span绑定，标记两者的父子链路关系
• 在Zipkin、Jaeger等分布式追踪平台中，你可以看到完整的调用链路：从上游服务的父Span出发，延伸到当前服务的子Span，再到后续调用的其他服务Span
• 日志中仅显示当前SpanID，但TraceID始终保持一致（示例中的affca7de79bdf483），结合追踪平台的链路数据，就能完整还原请求的全路径流转

3. RestTemplate调用行为的合理性 #

当当前服务通过RestTemplate调用外部API时，会创建新的子Span，并将该SpanID放入X-B3-spanID请求头。外部服务接收到请求后，同样会基于这个SpanID创建自己的子Span，以此实现链路的持续传递，这完全符合B3_MULTI传播策略的设计预期。

总结 #

• 服务器接收请求生成新SpanID是分布式追踪的标准设计，用于标记当前服务处理请求的独立单元
• 请求携带的上游SpanID是串联整个调用链路的关键，用于建立父子Span的关联关系
• 日志显示当前SpanID不影响链路追踪的完整性，结合统一的TraceID和追踪平台，可完整查看请求的全链路流转

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