Spring Cloud Sleuth迁移至Micrometer：填补功能缺口的方案探讨

AI 小北

2026-7-2

Sleuth迁移Micrometer的过渡方案探讨

我们当前使用BaggageFields和Sleuth在以下场景中传播自定义数据元素：

Sleuth表现稳定，但我们计划优先迁移到Micrometer。不过查阅文档并测试后发现，Micrometer目前不支持Kafka场景下的自定义数据传播。

我们注意到有一个为Kafka添加Micrometer instrumentation的提议，但目前暂无进展。

由于需要推进依赖该功能的应用向Spring Boot 3迁移，现探讨Micrometer提供支持前的过渡方案，希望获得相关建议：

方案1：Fork Sleuth代码并精简

相关疑问：
3. 除了Sleuth instrument包中的类，还需要引入哪些核心部分？
4. 是否有其他可选方案或建议？

需保留的Sleuth核心部分：
- BaggageFields相关的核心实现（包括baggage上下文管理、跨场景的传播逻辑）
- Kafka生产者/消费者的baggage拦截器及上下文传播代码
- @Async场景的上下文传播支持（如AsyncTaskExecutor的包装实现）
- Spring MVC/WebFlux的REST调用baggage传播集成代码
- 核心Trace上下文管理逻辑（若Micrometer的Trace上下文无法直接兼容Sleuth的baggage体系）
Spring Boot 3兼容修复点：
- 依赖与API版本适配：将Sleuth依赖的Spring Framework API升级到6.x版本，适配WebMvcConfigurer、AsyncConfigurer等接口的变动
- Jakarta EE替换：把所有javax.*包路径替换为jakarta.*（比如Servlet、JMS相关API）
- Micrometer版本对齐：升级Sleuth依赖的Micrometer版本至Spring Boot 3配套版本，处理MeterRegistry等类的API变更
- 废弃组件清理：移除Spring Boot 3中已淘汰的自动配置类，调整Sleuth的自动配置逻辑

除instrument包外需引入的部分：
- org.springframework.cloud.sleuth.baggage包下的核心类（BaggageManager、BaggagePropagator等baggage管理与传播核心）
- Trace上下文的核心抽象实现（如TraceContextHolder、自定义Propagator）
- 与Spring上下文集成的自动配置类（比如SleuthBaggageAutoConfiguration）
- @Async场景支持需引入org.springframework.cloud.sleuth.instrument.async下的任务执行器包装类
其他可选方案：
- 自定义Kafka拦截器：基于Micrometer Trace上下文，自行实现Kafka生产者/消费者拦截器，手动完成自定义baggage的提取、注入逻辑。无需依赖Sleuth，灵活性高，但需自行维护传播逻辑的一致性
- 分阶段迁移：先完成REST、@Async场景向Micrometer的迁移，Kafka场景暂时保留Sleuth实现，待Micrometer支持Kafka后再统一切换。需注意实现两者上下文的桥接，避免数据传播中断
- 社区贡献加速：如果团队资源允许，可以参与相关Kafka instrumentation提议的开发，推动功能落地

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