OpenTelemetry 毕业后，运维该如何重新理解可观测性

2026 年 5 月，CNCF 宣布 OpenTelemetry 毕业。这意味着它已经从一个快速发展的观测项目，成长为云原生可观测性领域的事实标准之一。

对运维学习者来说，这不是一个单纯的项目新闻。它代表监控体系正在从“每个工具各采各的指标”，转向“统一采集、统一协议、后端可替换”的方向。

传统监控的问题

过去我们做监控，通常会分别建设：

• Prometheus 采集指标。
• ELK 或 Loki 采集日志。
• Jaeger 或 Zipkin 做链路追踪。
• 每个语言 SDK 单独接入。
• 每个厂商都有自己的 agent。

这种方式能用，但问题也明显：

• 接入方式多。
• 字段命名不统一。
• 后端迁移成本高。
• 微服务链路难关联。
• 日志、指标、链路之间缺少共同上下文。

OpenTelemetry 的核心价值，就是让采集和传输标准化。

OpenTelemetry 解决什么

OpenTelemetry 主要关注 telemetry 数据的生成、采集、处理和导出，包括：

• traces：一次请求在多个服务中的调用链。
• metrics：CPU、请求量、延迟、错误率等指标。
• logs：日志事件。
• baggage：跨服务传递的上下文键值。
• OTLP：OpenTelemetry Protocol，用于传输数据。
• Collector：接收、处理、导出 telemetry 数据的组件。

你可以把 Collector 理解为可观测性管道中的“中转站”。

Collector 为什么重要

如果每个应用都直接把数据发到后端，架构会很混乱。Collector 可以统一处理：

• 接收 OTLP、Prometheus、日志等数据。
• 批量发送。
• 重试和队列。
• 过滤敏感字段。
• 增加资源标签。
• 导出到不同后端。

典型结构：

Application SDK -> OpenTelemetry Collector -> Prometheus / Tempo / Jaeger / Loki / Vendor Backend

这样后端变化时，应用代码不一定要改。

运维要先掌握三类信号

Metrics

指标适合回答“现在是否异常”。

常见指标：

• 请求量
• 错误率
• 延迟
• CPU
• 内存
• 队列长度

指标适合做告警。

Logs

日志适合回答“发生了什么细节”。

日志不是越多越好。好的日志应该包含：

• 时间
• 服务名
• 请求 ID
• 错误码
• 关键上下文

Traces

链路追踪适合回答“一次请求卡在哪里”。

微服务越多，traces 越重要。一次请求可能经过网关、用户服务、订单服务、数据库、缓存、消息队列，没有 trace 很难快速定位慢在哪。

从传统监控迁移的建议路径

不要一上来就全量改造。更稳的路径是：

1. 保留现有 Prometheus 和日志系统。
2. 先部署 OpenTelemetry Collector。
3. 让新服务接入 OTLP。
4. 给所有服务统一 service.name、deployment.environment。
5. 建立日志、指标、链路的 request id 关联。
6. 再逐步减少重复 agent。

Kubernetes 中的落地思路

在 Kubernetes 里，Collector 常见部署方式有两种：

• DaemonSet：每个节点一个，适合采集节点和本地日志。
• Deployment：集中接收应用 OTLP 数据，适合网关式采集。

很多生产环境会两种都用。

排障命令：

kubectl get pods -n observability
kubectl logs deploy/otel-collector -n observability
kubectl describe pod <collector-pod> -n observability

如果数据没有进后端，先看 Collector 日志，再看 exporter 队列和后端连接。

学习者容易踩的坑

只装 Collector，不做字段规范

没有统一字段，后面查询会很痛苦。至少要统一：

• service.name
• service.version
• deployment.environment
• k8s.namespace.name
• k8s.pod.name

只关注采集，不关注成本

链路和日志都可能带来大量数据。要学会采样、过滤和保留策略。

把 OpenTelemetry 当成监控后端

OpenTelemetry 不是 Prometheus、Loki 或 Jaeger 的替代品。它主要解决采集、标准和管道问题。

总结

OpenTelemetry 毕业代表可观测性标准化进入更成熟阶段。对运维工程师来说，未来不只要会看 CPU 和日志，还要理解 metrics、logs、traces 如何关联。

如果你正在学习云原生运维，建议从 Collector 开始，把一个简单 Web 服务的指标、日志、链路完整打通。这个练习会非常接近真实生产环境。

参考资料

• CNCF 宣布 OpenTelemetry 毕业
• OpenTelemetry Specification Status
• OpenTelemetry Status