Jaeger 分布式追踪

链路追踪后端需要 接收 Span、索引查询、Service Map 可视化。Jaeger 是 CNCF 毕业项目，常与 OTel Collector 配合，存储可用内存、Badger、Elasticsearch 或 Cassandra。本课讲部署与排障查询；概念见 obs-traces，采集见 dob-otel，指标关联见 prometheus-essentials，路线图见 /roadmaps/devops。

学习目标

• 部署 all-in-one Jaeger（开发）与 production 组件拆分（collector、query、storage）
• 在 UI 中按 service、operation、duration 筛选慢 Trace
• 理解采样率与存储成本的权衡

部署模式

All-in-one 适合 ops lab：单容器含 collector、query、UI、内存存储，重启丢数据。

# docker-compose 片段
services:
  jaeger:
    image: jaegertracing/all-in-one:1.57
    ports:
      - "16686:16686"   # UI
      - "4317:4317"     # OTLP gRPC
      - "4318:4318"     # OTLP HTTP
    environment:
      COLLECTOR_OTLP_ENABLED: "true"

生产 建议：OTel Collector 收 span → Jaeger Collector → Elasticsearch 持久化 → Jaeger Query + UI。与 obs-traces 中的 head/tail sampling 策略配合，ERROR 与 P99 慢请求强制保留。

排障工作流

1. Metrics 报警：http_server_requests_seconds P99 升高（prom-promql）
2. Jaeger 查 Trace：选 coderoadmap-backend，operation=GET /api/tracks，按 duration 排序
3. 定位 Span：展开 JDBC span，看 MySQL 查询是否占 80% 耗时
4. 日志 corroborate：用 traceId 在 Loki/ELK 搜同一请求日志

Trace abc123
  └─ platform GET /tracks     120ms
       └─ backend GET /api/... 115ms
            └─ jdbc query       98ms  ← 瓶颈

Service Map 可发现 platform → backend 调用异常边（错误率、延迟热力）。

练习

• 在 Jaeger UI 找到一次跨 platform + backend 的 Trace，标出最慢 Span
• 对比 all-in-one 与 ES 存储：各写一条适用场景
• 配置 OTel 采样率 10%，压测后估算每日 span 量级

小结

Jaeger 把 Span 变成可搜索的调用故事线，与 Metrics、Logs 通过 traceId 三角定位。 下一课看商业全栈 Datadog 如何一体化实现类似能力。