读 Seeing the Whole System

这篇 DZone 上的文章从一个事故应急响应的真实场景出发，讲透了可观测性（observability）领域最痛的问题：你的监控数据散落在四五个互不相干的系统里，出了事得靠人脑手动拼凑上下文。然后讲了 OpenTelemetry（简称 OTel）怎么从架构层面解决这个问题。

你可能也经历过的事故现场

事故响应进行到第 47 分钟，值班工程师已经开了 6 个浏览器 tab：Grafana 看基础设施指标，Splunk 搜应用日志，Jaeger 查链路追踪，还有一个 18 个月前谁搭的 Kibana 面板，还有一个团队 6 周前开通的 Datadog 试用版，但和其他系统完全没有打通。

根因是一个下游依赖在高负载下开始出现响应超时，导致某个没配队列监控的服务队列出现堆积。线索分布在四个互不相干的系统里，工程师得用脑子手动关联。

这个场景不是个例。大多数组织的监控工具链是这么长出来的：A 团队需要指标，上了 Prometheus；B 团队做链路追踪，选了 Jaeger；安全团队要日志聚合，部署了 ELK；新来的工程师喜欢 Datadog，自己开了个试用。每个决定单独看都没错，但最终结果是四五个互不相干的系统，各自只能看到环境的一部分。

当故障跨系统边界传播时（尤其在微服务环境下，经常出现这样的故障），代价就很明显了：不同系统之间的追踪数据无法互通——比如 A 服务用了 Jaeger 埋点，B 服务用了 Datadog 埋点，两个服务的 trace 数据对不上；一个系统的日志时间戳和另一个系统的指标尖峰对不上，还得花时间排除到底是时区不同还是真实的因果顺序。

OpenTelemetry 是什么

OTel 不是一个工具，而是一套规范（specification）+ API + SDK + Collector。它解决的核心问题是：让应用代码只管发射遥测数据，不关心数据发给哪个后端。

具体来说：

应用代码通过 OTel SDK 埋点，数据通过 OTLP （OpenTelemetry Protocol）协议发送
Collector 是一个独立的中间服务，负责接收、处理、路由遥测数据
切换后端（比如从 Jaeger 换成 Datadog）只需要改 Collector 配置，应用代码完全不用动

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024

exporters:
  otlp/jaeger:
    endpoint: jaeger:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/jaeger]

在 OTel 成熟之前（核心组件大约在 2023 年才达到生产稳定性），给应用做可观测性埋点意味着绑定某个厂商的 agent 或 SDK。想从 A 厂商换到 B 厂商？需要改代码、换库、重新测试。OTel 的厂商无关的设计把这个成本降到了配置变更。

Collector：最容易用错的组件

原文观察到团队对 Collector 有两种典型的误用：

*用得太简单*：把 Collector 当透传管道，原样转发所有数据到后端，不做过滤、采样、富化。配置虽然集中了，但浪费了中间处理层的能力
*过度复杂化*：一开始就往 5 个后端同时发数据，加上复杂的处理器链和多套采样策略。6 个月后没人能完整解释这个配置

做得好的团队遵循一个模式：从一个 receiver、一个 processor、一两个 exporter 开始，逐步扩展。Collector 配置放 Git 里，变更走 code review。Collector 本身也当服务对待——有 owner、有 SLO、有值班轮换。

一个实用的 Collector 模式是 tail-based sampling （尾部采样）：在源头全面埋点，在 Collector 层配置只把 10-15% 的 trace 发到昂贵的存储后端，但保留 100% 的错误和慢请求 trace。该看的问题一个不漏，但摄入成本大幅降低。

关联查询：统一遥测最大的价值

统一遥测标准最大的好处不是省钱或换后端方便，而是可以做关联查询——从一个指标异常，跳到解释它的 trace，再跳到定位具体操作的日志行。

OTel 的 trace 上下文传播机制（即请求从 A 服务调到 B 服务时，自动把 trace ID 带过去）让这个关联变成自动的：同一个请求经过的每个服务都用同一个 trace ID 串起来：

# traceparent header 格式：version-trace_id-parent_id-trace_flags
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

如果你的日志也带着这个 trace ID （OTel 的日志埋点会处理），就可以从 trace 中的慢 span 直接跳到该 span 产生的日志行，在一个系统里完成。原文提到一个初级工程师用这种方式做了根因分析，值班负责人估计这在 OTel 迁移前要 40 分钟，实际只用了 9 分钟。

还没有解决的问题

*自动埋点的局限*：OTel 的 auto-instrumentation 对标准 HTTP 调用、数据库查询、gRPC 很好用，但对自定义消息队列、遗留协议、内部框架仍然需要手动埋点——这部分工作很麻烦
*日志集成滞后*：trace 和 metric 在 OTel 中已经成熟稳定，但日志规范的 SDK 实现仍在追赶。原文建议的渐进策略是：先在现有日志输出中加上 trace ID 和 span ID，等运维图景更清晰后再迁移收集路径
*Collector 本身需要维护*：处理几十个服务的高基数遥测数据的 Collector 需要容量规划、故障分析、持续运维。不能当"设好就忘"的组件

推荐订阅源

暗无天日

目录