OpenTelemetry（OTel）正式成为 CNCF 毕业项目，和 Kubernetes、Prometheus 等成熟开源项目站在了同一行列。这不是“所有团队明天都必须迁移”的信号，而是一个更清晰的判断依据：OTel 的标准、生态和治理已经足够成熟，值得被纳入长期可观测性规划。
真正的问题因此从“要不要关注 OTel”变成了“如何把它落到现有服务、采集链路和运维流程中”。
毕业意味着什么
CNCF 的毕业状态通常意味着项目在技术成熟度、社区治理、贡献者结构和生产使用方面达到了较高要求。对工程团队来说，最直接的价值有三点：
- 可以更有信心地采用 OTel 的采集模型和数据语义。
- 可以减少对单一厂商 SDK 或私有埋点格式的绑定。
- 可以围绕统一的 traces、metrics 和 logs 管道建设可观测性平台。
但“毕业”不等于所有组件都已经完美，也不等于迁移没有成本。不同语言 SDK、Collector 组件、后端存储和供应商集成的成熟度仍然可能不同。团队仍应从实际故障场景和服务边界出发，逐步验证。
先统一数据入口，再扩大覆盖面
OTel 的一个重要实践方向，是让应用通过 OTLP 将遥测数据发送到 OpenTelemetry Collector，再由 Collector 负责处理和转发。这样应用代码不必直接依赖某个具体的可观测性后端。
可以这样理解这条链路：
应用服务 -> OTLP -> OpenTelemetry Collector -> 日志、指标或链路后端
Collector 可以承担批处理、属性过滤、采样、路由和导出等职责。应用只需要关心如何生成标准化遥测数据，平台团队则可以集中管理出口和策略。
这种拆分尤其适合多团队、多语言的服务环境：Java、Go、Python 或 Node.js 服务可以使用各自的 OTel SDK，但共享同一个采集入口和运维规范。
一个可运行的 Collector 起点
下面是一个最小的 Collector 配置。它接收 OTLP 的 gRPC 和 HTTP 数据，并通过 debug exporter 输出到 Collector 容器日志，适合本地验证和开发环境。生产环境可以把 debug 替换为实际的后端 exporter。
创建 otel-collector.yaml：
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
exporters:
debug:
verbosity: basic
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [debug]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [debug]
logs:
receivers: [otlp]
processors: [batch]
exporters: [debug]
使用官方 Collector 镜像启动：
docker run --rm --name otel-collector \
-p 4317:4317 \
-p 4318:4318 \
-v "$PWD/otel-collector.yaml:/etc/otelcol-contrib/config.yaml:ro" \
otel/opentelemetry-collector-contrib:latest \
--config=/etc/otelcol-contrib/config.yaml
应用可以通过以下地址发送 OTLP 数据：
- gRPC：
localhost:4317 - HTTP：
http://localhost:4318
这个配置只用于验证链路是否打通。上线前还需要根据数据量配置资源限制、队列、重试、持久化和认证，并评估采样策略。debug exporter 也不适合作为生产数据出口。
从一个故障场景开始迁移
不要一开始就为所有服务补齐三种信号。更可控的路径是选择一个有明确收益的场景，例如：
- 为跨服务调用补充 trace 和统一的
service.name。 - 为高延迟接口增加数据库、缓存和下游 HTTP 调用的 span。
- 为关键业务指标建立统一的资源属性和环境标签。
- 让 Collector 在一个环境中承担统一采样和转发。
迁移时需要提前约定服务名、环境、版本和实例标识等资源属性。否则即使数据成功进入后端，查询时也会出现服务名称不一致、环境无法区分等问题。
同时要控制高基数属性。用户 ID、订单 ID、完整 URL 或异常堆栈不应未经评估就写入 metrics 标签。它们可能造成时间序列数量和存储成本快速增长，更适合出现在 trace span 或日志字段中。
采用清单
团队可以用下面的清单评估下一步工作：
- 选定一个真实故障或性能问题作为试点。
- 统一
service.name、环境和版本等资源属性。 - 优先建立 OTLP 到 Collector 的标准入口。
- 明确 traces、metrics、logs 各自的保留周期和成本上限。
- 验证采样、重试、队列和后端不可用时的行为。
- 检查敏感数据和高基数属性是否会被采集。
- 为告警、排障手册和服务等级目标绑定可观测性数据。
OpenTelemetry 毕业的意义，不是让可观测性变成一次大规模重写，而是让团队拥有更稳固的共同基础。比较务实的做法是从一个服务、一条链路和一个明确的问题开始，验证数据质量与运维收益，再逐步扩大覆盖范围。