成了标准之后，OpenTelemetry 要不要跟

先给结论：新项目直接上 OTel，老项目看你是不是「多供应商」或「有合规审计需求」——两样都不沾，现有 SDK 跑得稳就不用动。

这个判断不是从版本号推出来的，是从「可观测性这一层到底在解决什么问题」反推出来的。下面先说发生了什么（只留跟你有关的部分），再说它对你手上那套系统意味着什么，最后给跟/不跟各自的条件。

发生了什么

2026 年 5 月，CNCF 宣布 OpenTelemetry 正式毕业（公告原文），和 Kubernetes、Envoy 同一档——意味着 API 稳定、生产验证充分、治理结构成熟。CNCF 那篇后续文章（Now what?）把下一阶段的重心放在声明式配置、性能剖析（Profiling）和 eBPF 探针上。

拆开看三支柱各自的成熟度，差别不小：

• Traces：最稳。API / SDK 从 1.0 起就没动过，各语言实现齐全，主流后端（Jaeger、Tempo、Zipkin、各家商业产品）全认 OTLP 协议。
• Metrics：在追。API 稳定但语义约定（Semantic Conventions）还在补，特别是 JVM / 数据库 / 消息队列这几族指标名还在微调。
• Logs：刚进 1.0 不久。Bridge 模式（把现有日志框架的输出转成 OTel 格式）已经可用，但「从代码到后端全链路统一 OTel」的体感还没到 Traces 那一级。
• Profiling：还在 Sandbox，不是 1.0，暂时不纳入选型考量。

一句话概括：Traces 可以放心全量用，Metrics 够用但要接受语义约定还会微调，Logs 看场景，Profiling 再等一年。

它到底在解决什么问题

可观测性这一层，过去十年的常态是：每个后端供应商绑一套 SDK。Datadog 有 Datadog Agent + 各语言 tracer，New Relic 有 New Relic Agent，Elastic 有 APM Agent，AWS 有 X-Ray SDK。你选了哪家的后端，就得在代码里引哪家的包、配哪家的 Agent。

这带来两个问题：

1. 换后端等于换 SDK：从 Datadog 迁到 Tempo，代码里所有 @Traced 注解和初始化代码都得重写。供应商锁定不在协议层，在 SDK 层。
2. 多信号不统一：Traces 走一家、Metrics 走另一家、Logs 走第三家，三个系统各有一套标签体系，排障时无法从一条 Trace 直接跳到关联的 Metrics 和 Logs。

OTel 解决的是发射端的标准化：不管你后端用谁，代码里只引一套 OTel SDK、走一个 OTLP 协议发出去。后端那侧可以接 Jaeger、Tempo、Prometheus、Loki、或者任何商业产品——换后端不改代码。

注意：OTel 不管存储和查询，只管采集和传输。 它不替代 Prometheus，也不替代 Jaeger——它是这些工具前面那一层统一协议。

Collector 那一层：绕不过去的中间件

OTel 架构里有一个绕不过去的组件：OTel Collector。它是一个独立进程，负责接收 OTLP 数据、做处理（过滤、脱敏、采样、格式转换）、再转发给后端。

为什么需要它：

• 应用侧不想直连后端：Collector 做一层缓冲，后端切换时只改 Collector 的配置，应用侧不动。
• 跨协议桥接：你的应用发 OTLP，但后端只收 Prometheus 拉取格式——Collector 做转换。
• 采样与脱敏：在高流量场景下，Collector 做 tail-based sampling（按 Trace 完整度决定留不留），比应用侧的 head-based sampling 精准得多。

代价也很实在：

• 多一个进程要运维：Collector 本身吃内存（典型配置 100-300 MiB），需要健康检查、日志轮转、升级策略。
• 配置是 YAML 不是代码：调试体验不如应用侧的代码，出问题时定位链路多了一跳。

小团队（日请求量 < 100 万、单后端、无合规需求）可以跳过 Collector，应用侧 SDK 直连后端。等流量或合规需求上来了再部署 Collector，不需要改应用代码。

Spring Boot 项目接入的实际代价

如果你用的是 Spring Boot 3.x 或更新版本，接入 OTel 的代价比想象中低——但也没有低到「零配置」。

已经帮你做好的：

• Micrometer（Spring 的可观测性抽象层）原生支持 OTLP 导出，Metrics 和 Traces 两条路都通。management.otlp.metrics.export.enabled=true 加一行配置，Micrometer 的 MeterRegistry 就开始往 OTLP 端点推数据。
• Spring Boot Actuator 的 @Timed、@Counted 注解不需要改，底层自动从 Micrometer 的注册表走。
• Spring Cloud Sleuth 已被 Micrometer Tracing 替代（从 Spring Boot 3.2 起），后者原生支持 OTLP 和 W3C Trace Context 传播。

还得自己做的：

• Logs 那一桥：Spring Boot 默认用 Logback，要让它输出 OTel 格式的日志需要加一个 opentelemetry-logback-appender-1.0 依赖并在 logback.xml 里配一行。不复杂，但不是零配置。
• 语义约定的对齐：Spring Boot 自动配置的指标名（http.server.requests 等）已经在往 OTel 语义约定靠，但数据库层、消息队列层的指标名可能还没完全对齐——如果你要跨服务统一查询，得在 Collector 侧做一层 metrics transform。
• Collector 的部署：如果用 Collector，得自己写 otelcol-config.yaml、管它的生命周期。Kubernetes 环境有 Helm chart，裸机环境得自己管进程。

一个真实的接入清单（Spring Boot 3.x + OTel Metrics/Traces/Logs 全开）：

1. pom.xml 加 micrometer-registry-otlp + micrometer-tracing-bridge-otel + opentelemetry-exporter-otlp
2. application.yml 写 management.otlp.metrics.export.endpoint 和 management.otlp.tracing.endpoint
3. logback.xml 加 OTel appender
4. 如果要 Collector：部署 Collector 并改 endpoint 指向 Collector 地址

大约半小时到一小时的工作量。不是大工程，但也不是「升个版本就完事」。

跟的条件

满足以下任意一条，建议跟：

1. 多供应商 / 可能换后端：你在用 Datadog 但合同快到期了，或者公司在评估从商业产品迁到开源栈——OTel 让你换后端时不改代码。
2. 合规审计需求：金融、医疗、政务类项目，审计要求「可观测性数据不能绑死在单一供应商」，OTel 是现成的答案。
3. 新项目从零开始：没有历史包袱，直接选 OTel 标准，未来不用还债。
4. 多语言栈：Java + Go + Python + Node 混合环境，OTel 是少数「各语言 SDK 成熟度对齐」的方案。

不跟的条件

满足以下全部条件，现有 SDK 跑得稳就不用动：

1. 单一后端、没有切换计划：你用 Jaeger 用得挺好、不打算换，那 OTel 对你只是多一层抽象。
2. 团队小、运维带宽紧：引入 Collector 意味着多一个要管的组件。如果团队里没人能 debug Collector 的 YAML 配置，先不急。
3. 现有 SDK 深度绑定：你的代码里到处是 @DatadogTag 或 NewRelic.addCustomParameter，替换成本远高于收益——这种场景不如等下次重构时再统一。
4. 可观测性不是当前瓶颈：你的系统还在日活几千的阶段，日志加 grep 就够排障，引入 OTel 是过度工程。

一张表收口

你的情况	建议
新项目、从零开始	直接上 OTel，半小时接入成本
老项目、单一后端、无切换计划	不动，等下次重构再说
老项目、后端合同快到期	现在就开始评估 OTel 迁移
多语言栈	OTel 是目前最整齐的多语言方案
合规要求不能绑单一供应商	OTel 是现成答案
团队 < 5 人、运维带宽紧	先跳过 Collector，SDK 直连后端
日请求量 < 100 万	Collector 不急，先跑 SDK 直连

最后一句：OTel 毕业不是一个「要不要关注」的新闻，它是一个「你的可观测性栈要不要对齐到这个标准」的决策。 决策的依据不是版本号，而是你有多大概率换后端、你的团队能不能多管一个 Collector、你现在的 SDK 锁得有多深。三个问题答完，跟不跟就有数了。