Jaeger（耶格）
Jaeger（德语「猎人」，发音类似「耶格」）是 CNCF 毕业的开源分布式追踪系统，由 Uber 于 2017 年开源。它解决微服务架构下「一个请求经过 N 个服务，哪里慢、哪里错」的难题——通过 OpenTelemetry SDK 给每个请求打上唯一的 traceID，记录它在每个服务里的处理段（span），组成一棵调用树（trace），让开发者像看 X 光片一样看到请求在分布式系统里的完整流转。在微服务架构里，没有分布式追踪，排障只能靠「SSH 到每个服务 grep 日志」盲目拼接，效率极低；Jaeger 把这个链路可视化出来，是可观测性三大支柱（指标/日志/追踪）之一「追踪」的事实标准。它原生支持 OpenTelemetry（OTel），是 OTel 的主要后端之一；也兼容 Zipkin 格式（Zipkin 是更早的开源追踪系统，已基本并入 OTel 生态）。
Jaeger 的全部考点围绕分布式追踪核心概念展开：①trace/span 模型（trace 是一次请求的完整链路，span 是每个服务/操作的处理段，parent/child 组成树）；②OpenTelemetry 集成（OTel SDK 埋点 + 传播 + 导出，Jaeger 作后端）；③采样策略（头部采样 vs 尾部采样，概率采样 vs 速率限制，控制上报量）；④存储后端（Cassandra/ES/内存，按 traceID 查找）；⑤与 Zipkin 的关系（Zipkin 并入 OTel 生态，Jaeger 兼容其格式）；⑥与 Tempo 的对比（Tempo 按 traceID 查省存储、弱属性检索，Jaeger 原生支持属性检索）。本叶是可观测性追踪层的总览与地基，讲清它的 trace/span 模型、OTel 集成、采样策略与存储——后续在前 4 叶（Prometheus/Grafana/ELK/Sentry）的基础上补齐全栈可观测性。
评价
优点
- trace/span 模型清晰：把「请求在分布式系统的流转」建模为树，每段处理是一个 span，耗时/错误/依赖一目了然
- OpenTelemetry 原生：作为 OTel 主要后端，与 OTel SDK 无缝集成，埋点一次导多处（Jaeger/Tempo/Datadog）
- 属性检索强：可按 service/operation/tags/latency/status 等属性检索 trace，不用先知道 traceID
- CNCF 毕业成熟：Uber 出品，CNCF 毕业项目，生产验证充分，社区活跃
- Zipkin 兼容：支持接收 Zipkin 格式数据，迁移成本低
缺点
- 存储与索引成本高：原生用 Cassandra/ES 存 trace + 索引属性，比 Tempo（不索引属性，按 traceID 查）成本高
- 采样必要但有损：高流量场景必须采样（否则成本爆炸），采样会丢部分 trace
- 属性检索 vs 存储：与 Tempo 的取舍——强属性检索（Jaeger）带来高存储，省存储（Tempo）弱检索
- 不存所有 trace：受采样影响，不是每个请求都有 trace，排障可能恰好丢
- 自托管运维重：Cassandra/ES 集群 + Jaeger collector/query 多组件，运维成本不低
本叶地图
- 入门 —— Jaeger 是什么、trace/span 模型、OpenTelemetry 集成、采样策略、与 Zipkin/Tempo 的关系
- 分布式追踪 —— trace/span 树结构、span 上下文传播（W3C Trace Context）、OTel SDK 埋点导出、Jaeger 后端架构
- 采样与对比 —— 头部 vs 尾部采样、概率/速率限制策略、Zipkin 并入 OTel、与 Tempo 的检索/存储取舍
- 参考 —— OTel SDK 集成速查、span 属性速查、采样配置、易错点