linux-sre-handbook

05-分布式追踪

为什么需要分布式追踪

微服务架构中，一个请求可能经过几十个服务。追踪让我们能：

核心概念

Trace (一次完整请求)
 ├─ Span 1 (Service A 处理)
 │   ├─ Span 1.1 (调用 Service B)
 │   └─ Span 1.2 (调用 Redis)
 └─ Span 2 (Service B 处理)
     ├─ Span 2.1 (查询 MySQL)
     └─ Span 2.2 (调用 Service C)
概念 说明
Trace 一次完整的请求链路
Span 链路中的一个操作单元
Trace ID 全局唯一，贯穿整个链路
Span ID 单个 Span 的唯一标识
Parent Span ID 父 Span ID（建立层级关系）

OpenTelemetry 标准

CNCF 的可观测性标准，统一 Metrics / Logging / Tracing 数据采集。

SDK / API → Collector → Backend
           (OTLP 协议)   (Jaeger / Tempo / Datadog)

关键概念：

Jaeger

Uber 开源的分布式追踪系统：

Application (Jaeger Client)
      ↓ (jaeger.thrift over UDP)
Jaeger Agent
      ↓
Jaeger Collector → Kafka → Jaeger Ingester
                        ↓
                  Elasticsearch / Cassandra
                        ↓
                  Jaeger Query (UI)

Grafana Tempo

排查实战

1. 用户反馈"API 慢"
2. 在 Grafana 检查 RED 看板 → p99 延迟飙升
3. 看 Tracing → 某个 Trace 在 Service D 耗时 3 秒
4. 展开 Service D 的 Span → 发现 MySQL 查询慢
5. 关联 Loki 日志（按 Trace ID）→ 看到慢查询 SQL
6. 定位：缺少索引的全表扫描

延伸阅读