在建立微服务程序时链路追踪已成为诊断性能瓶颈与错误定位的必备工具。只是在实际项目中常见的痛点让开发者头疼不已：

• **配置繁琐**：不同框架需要分别配置传播逻辑。
• **缺失自动化**：Spring Cloud Gateway 自动传播。但其它组件多为手动注入，容易遗漏。
• **依赖冲突**：Dubbo 的 OpenTelemetry 自动配置与 Spring Boot 的 starter 冲突，导致启动失败。其实，
• **Metrics 导出错误**：本地开发环境缺少 OTLP Collector。默认推送 Metrics 会报 “Connection refused”。
• **日志可观测性不足**：难以在日志中直观看到 traceId 与 spanId，导致跨服务调试效率低。

一、依赖引入

Main 分支

统一使用单一 starter：

org.springframework.boot
spring-boot-starter-opentelemetry

该 starter 包含：

• spring-boot-opentelemetry: 创建 OpenTelemetry Bean
• spring-boot-micrometer-tracing-opentelemetry: 创建 Tracer Bean
• micrometer-tracing-bridge-otel: OTel 桥接实现
• opentelemetry-exporter-otlp: OTLP 数据导出器

SprintBoot3 分支

此分支仍在 spring-boot-starter-actuator 中自动配置 tracing，只需额外添加桥接：

io.micrometer
micrometer-tracing-bridge-otel

为什么要换？老实说，

Spring Boot 将链路追踪拆分到了独立 starter。若仅引入桥接包，启动时会报如下错误：

1. "required a bean of type 'io.opentelemetry.api.OpenTelemetry' that could not be found"
2. "required a bean of type 'io.micrometer.tracing.Tracer' that could not be found"

后请用sprint‑boot‑starter‑opentelemetry 替换原来的 micrometer‑tracing‑bridge‑otel。以避免遗漏关键依赖，

二、主要配置细节

采样率统一设置全量采样

management:
tracing:
sampling:
probability: 1.0

OTLP Metrics 导出关闭

sprint‑boot‑starter‑opentelemetry 内置了 micrometer-registry-otlp，默认向 http://localhost:/v1/metrics 推送。 若本地无 OTLP Collector，会报 Connection refused。

management:
otlp这方面，metrics:
说到export。enabled: false

再看注意，如果你使用的是 springboot3 分支，则无需此配置，因为桥接包不包含 Metrics 导出模块。

Dubbo 模块额外配置 

dubbo:
tracing:
enabled: true

Maven 项目需排除 Dubbo 自带的 OpenTelemetryAutoConfiguration。以免与 Spring Boot 的 otelSpanProcessor Bean 冲突：

@SpringBootApplication(exclude = {
org.apache.dubbo.spring.boot.autoconfigure.observability.otel.OpenTelemetryAutoConfiguration.class})
public class MyApplication { /* ... */ }

SprintBoot3 分支无冲突，可直接使用桥接包，无需排除。

三、Trace 传播策略对比表格

传播方式  是否自动/手动/自定义 原因/配置信息 实现类名称。或者插件名称，例如 opentelemetry-instrumentation-spring-webmvc-v170.jar 等文件名，也可以直接复制到 IDE 打开查看源码来学习其工作原理-->/--'''''''''''role'=>'cell'>