OpenTelemetry

概述 你有没有遇到过这种情况：用户反馈"系统好卡"，你打开 Grafana 看了一堆面板，CPU 正常、内存正常、网络也正常，但用户就是说慢。这时候你需要的不是更多的指标面板，而是一条完整的请求链路——从用户点下按钮到数据库返回结果，每一跳花了多少时间，卡在哪一步。 这就是 APM（Application Performance Monitoring，应用性能监控）干的事。 简单说：日志告诉你发生了什么，指标告诉你系统是否健康，APM 告诉你为什么慢、慢在哪里、影响了谁。三者各管一摊，缺一不可。 本文从实际选型角度出发，拆解主流开源和商业 APM 工具的架构差异、适用场景和坑点。不吹不黑，每家都有适合的场景，关键看你的团队规模、技术栈和预算。 APM 要解决什么问题 先说清楚为什么需要 APM，而不是直接跳到工具对比。 微服务架构下的"链路黑盒" 单体应用时代，一个请求从入口到数据库都在一个进程里完成，打个断点就能调试。微服务拆分后，一个用户请求可能经过 API 网关 → 认证服务 → 订单服务 → 支付服务 → 消息队列 → 库存服务 → 数据库，中间还穿插着 Redis 缓存和第三方 API 调用。 任何一个环节变慢，整体就慢。但你看日志只能看到单个服务的视角，没法把整条链路串起来。这就像你在医院看病，内科查完说没问题让你去外科，外科查完说没问题让你去骨科——每个科室都说自己没问题，但你就是难受。APM 就是那个能把你所有科室检查结果串起来看的"全科医生"。 APM 的三个核心能力 能力 解决什么问题 类比 分布式追踪（Distributed Tracing） 一个请求经过哪些服务、每跳花了多久 快递物流追踪，每个中转站都有时间戳 性能剖析（Profiling） 某个函数执行慢，CPU 花在哪了 体检报告，精确到每个器官的指标 错误追踪（Error Tracking） 异常发生在哪个服务的哪行代码 车辆故障码，直接定位到故障部件 分布式追踪是 APM 最核心的能力。它通过在请求入口生成一个唯一的 Trace ID，然后通过 HTTP Header 或 RPC 上下文传递到下游服务，每个服务在自己的处理过程中记录一个 Span（你可以理解为链路上的一个节点），最终拼出完整的调用树。 关键概念速览 术语 含义 说明 Trace 一次完整的请求链路 由多个 Span 组成的有向无环图（DAG） Span 链路上的一个操作节点 包含操作名、起止时间、标签、日志 Context Propagation 上下文传递 Trace ID 通过 HTTP Header 在服务间传递 Sampling 采样 不可能记录所有请求，按策略采样部分 Instrumentation 探针/埋点 代码层面自动或手动注入追踪逻辑 采样策略很关键。线上流量大的时候，全量记录 Trace 会把存储和 CPU 吃干。常见做法是头部采样（Head-based Sampling）——在请求入口决定是否记录，要么整条链路全记，要么全不记。尾部采样（Tail-based Sampling）更精细——在链路结束时根据条件（比如耗时超过阈值、出现错误）决定是否保留，但实现复杂度高，需要中间层缓存完整链路。...

概述 在云原生和微服务时代，一个请求可能跨越数十个服务节点。传统的监控方式将 Metrics、Logs、Traces 分散在不同系统中——Prometheus 看指标、ELK 搜日志、Jaeger 追链路，三者之间没有统一的关联方式。当线上故障发生时，你需要在三个系统之间来回切换，手动拼接关联信息，效率低下。 OpenTelemetry（简称 OTel）是 CNCF 主导的可观测性统一标准，目标是用一套 SDK/API 统一采集三大信号（Metrics、Logs、Traces），通过统一的 Collector 处理后发送到任意后端。它不替代后端存储和可视化，而是解决"数据采集层碎片化"的问题。本文深入讲解 OTel 的规范、架构、实践和迁移策略。 参考来源：OpenTelemetry 官方文档、CNCF OpenTelemetry 规范 一、为什么需要 OpenTelemetry 1.1 可观测性碎片化问题 传统可观测性架构（碎片化）： 应用代码 ├── Prometheus Client (Metrics) │ └── → Prometheus → Grafana ├── Logback + Filebeat (Logs) │ └── → Elasticsearch → Kibana └── Jaeger Client (Traces) └── → Jaeger → Jaeger UI 问题： 1. 三套 SDK，三套配置，三套运维 2. Metrics / Logs / Traces 之间无关联（TraceID 未关联到日志） 3....

为什么需要分布式追踪 微服务架构下，一个用户请求往往要穿越多个服务。当某个接口耗时从 200ms 飙升到 2s 时，日志散落在 N 台机器上，你很难判断瓶颈在哪一层——是网关转发慢、下游 DB 查询慢、还是某个服务间调用排队？ 分布式追踪（Distributed Tracing）解决的就是这个问题：它为每个请求生成一个全局唯一的 Trace ID，在服务间透传，最终在 UI 上画出一条完整的调用链路树，让每一段耗时一目了然。 Jaeger（发音类似"耶格"）由 Uber 开源，现为 CNCF 毕业项目。本文基于 Jaeger v1.60+ 和 OpenTelemetry SDK 进行实践。官方文档 分布式追踪核心概念 Trace 一个 Trace 代表一次完整的分布式请求链路，由唯一的 128-bit Trace ID 标识。它是一棵由多个 Span 组成的树形结构： Trace (TraceID: a1b2c3...) ├── Span: HTTP GET /api/orders [gateway] │ ├── Span: RPC GetUser [user-service] │ │ └── Span: SELECT * FROM users [mysql] │ └── Span: RPC GetOrderList [order-service] │ └── Span: Redis GET [redis] Span Span 是追踪的最小单元，记录一次操作的开始和结束。关键字段：...