Jaeger 链路追踪
jaeger;分布式 trace。
30 分钟
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 慢请求强制保留。
排障工作流
- Metrics 报警:
http_server_requests_secondsP99 升高(prom-promql) - Jaeger 查 Trace:选
coderoadmap-backend,operation=GET /api/tracks,按 duration 排序 - 定位 Span:展开 JDBC span,看 MySQL 查询是否占 80% 耗时
- 日志 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 量级