Jaeger 与 Tempo 实战

为什么必须采样:全量存储的不可行性

先做一个定量估算.一个中等流量的服务每秒处理 1 万个请求,每个请求产生几十个 Span:

10000 req/s × 30 span/req = 30 万 span/s
每个 span 包含名称,时间,属性...约 1KB
  → 约 300 MB/s = 约 26 TB/天

而其中绝大多数追踪内容如何?
  → 99% 是"一切正常,快速返回"的请求 -- 这些追踪几乎没有排障价值
  → 真正需要关注的是那 1% 出错或延迟异常的部分

全量存储每日 26TB 的追踪数据,成本极高,且 99% 为低价值的正常请求追踪.因此采样(Sampling)--仅保留一部分追踪--不是优化选项,而是必选项.问题的关键在于:如何智能地选择保留哪些追踪数据.

两种采样策略:头部采样与尾部采样

采样的时机决定了其智能程度.这是本篇的核心知识点.

头部采样(Head-based Sampling):在请求入口做出决策

在请求刚进入系统时即决定是否追踪该请求--例如"随机保留 1%".决策在"头部"(链路入口)做出,此后整条链路要么全量追踪,要么完全不追踪.

• 优点:实现简单,开销极低(早期决策使后续服务无需缓存数据)
• 关键缺陷:决策时尚不知道此请求是否会出错或变慢.结果是--最需要查看的那条 2 秒超时的请求,有 99% 的概率恰好未被采到,待需要排查时该追踪数据根本不存在.

尾部采样(Tail-based Sampling):在请求完成后做出决策

等待一条追踪的所有 Span 全部完成后,基于"本次请求的完整信息"再决定保留与否--例如"出错的全部保留,延迟高的全部保留,正常的仅保留 1%".决策在"尾部"(链路结束)做出.

• 优点:能够精准保留有价值的追踪数据--出错的,延迟高的一条不漏,正常的大比例稀释.这正符合排障需求.
• 代价:需将一条 trace 的所有 Span 暂存至请求结束(因为 Span 来自不同服务,陆续到达),需要更多内存和更复杂的组件(通常由 OTel Collector 承担).

回顾第 04 篇日志采样的基本原则--"保留异常,稀释正常,ERROR 级别绝不采样".尾部采样将相同策略应用到追踪领域,且实现得更为彻底:因为它等待请求结束并获取完整结果后才做出决策,所以能够精确地"仅保留出错和延迟异常的请求".

**这是可观测性应对海量数据的通用思想在不同支柱上的同一种体现.**在条件允许的情况下应优先使用尾部采样,这是生产级追踪的推荐做法.

头部采样:  请求进入 → 随机决策(1% 保留)→ ...→ 结束
           ✗ 决策时不知结果,最需查看的错误请求大概率未被保留

尾部采样:  请求进入 → 全程暂存 Span → 结束,查看完整结果 → 决策
           ✓ "本次出错/超时 → 保留!" "本次正常 → 以 1% 概率保留"

Jaeger:经典的追踪系统

Jaeger(Uber 开源,CNCF 项目)是追踪领域长期使用的主力方案,提供完整的功能栈:Span 接收,存储,查询,以及经典的瀑布图 UI.

• UI 成熟:瀑布图,服务依赖拓扑图,Trace 对比,排障体验完善
• 存储可替换:后端可对接 Cassandra,Elasticsearch 等
• 原生支持 OTel:直接接收 OTLP 数据(见第 06 篇),无需厂商专用 SDK

第 06 篇练习中"在 Jaeger UI 查看瀑布图",即是 Jaeger 将收到的 Span 按 trace_id 组装为树,绘制为时间线的结果.

Tempo:将 Loki 的低成本策略应用于追踪

Tempo(Grafana 出品)对追踪数据的处理方式与 Loki 对日志的处理方式完全一致,设计理念一脉相承:

查询追踪时,绝大多数场景是通过已知的 trace_id 直接查询(从指标的异常点,从日志的某条记录获取 trace_id,然后查看其完整链路).既然如此,无需为追踪的各类字段建立索引.仅按 trace_id 建立索引,Span 数据整体压缩后存入对象存储(S3)即可.

实战:一次慢请求的完整定位

将第 06,07 篇的内容串联起来,重新走一遍第 01 篇凌晨的排障流程--这次有了完整的追踪能力.以下第 2 步用到 exemplar:它是附加在指标数据点上的一个"样例 trace_id",使我们能够从一个聚合的指标点跳转到一条具体的代表性追踪(原理在第 08 篇详细说明,此处先理解"指标点上可附带一个 trace_id"即可).

┌──────────────────────────────────────────┐
│ ① 指标告警:下单 P99 = 2s<br/>(Prometheus,第03篇) │
└──────────────────────────────────────────┘
                      │
                      ▼
┌────────────────────────────────────────────────────────────────────┐
│ ② 在 Grafana 看板的延迟图上<br/>点击一个慢请求的 exemplar<br/>→ 获取 trace_id=a1b2c3 │
└────────────────────────────────────────────────────────────────────┘
                                   │
                                   ▼
┌───────────────────────────────────────────────────────┐
│ ③ 使用 trace_id 在 Tempo 查询链路<br/>→ 瀑布图显示:支付服务调用跳 1820ms │
└───────────────────────────────────────────────────────┘
                            │
                            ▼
┌──────────────────────────────────────────────────────────┐
│ ④ 使用同一 trace_id 在 Loki 查询日志<br/>→ 发现:第三方网关 429 限流,重试 3 次 │
└──────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────┐
│  根因定位完成  │
└──────────┘

注意这条路径中,trace_id 是贯穿始终的线索:从指标的 exemplar 获取它,用它取追踪,查日志.三个独立的系统(Prometheus/Tempo/Loki),通过这一个 ID 串联为一次连贯的排障流程.这就是第 08 篇将要系统论述的"关联",而追踪在其中承担"定位到哪个调用跳"的关键角色.

这是采样固有的风险,也是尾部采样优于头部采样的实际意义所在:使用尾部采样时,"出错,延迟高"的请求被规则强制保留,因此从告警追查的那条慢 trace,大概率已被存储.若使用头部随机采样,则很可能无法找到.

这也是为什么:追踪和日志应采用同一套"保留异常"的采样策略,否则在日志中看到了 trace_id,在 Tempo 却查无此 trace--两个支柱的采样策略不一致,关联即告中断.