2. Jaeger 基础架构：组件、数据模型与部署模式
Jaeger 是 CNCF 毕业的分布式追踪系统，其架构围绕“采集—存储—查询”三条主线设计。理解 Jaeger 的组件职责、数据模型和部署模式，是后续在 GameDay 实验中构建追踪基线、定位性能拐点的前提。
2.1 核心组件与职责
Jaeger 由四个主要组件构成，它们各自承担追踪数据生命周期中的关键环节：
| 组件 | 角色 | 关键职责 | GameDay 关注点 |
|---|---|---|---|
| Agent | 边车代理 | 接收应用发出的 UDP 数据，批量转发至 Collector；支持采样策略下发 | Agent 丢包或延迟会导致追踪基线缺失，需监控其缓冲区状态 |
| Collector | 数据管道 | 验证、索引、存储 Span；支持 gRPC/HTTP 接收；可做二次采样 | Collector 是吞吐瓶颈高发区，GameDay 中常注入延迟或限流来验证背压机制 |
| Query | 查询服务 | 提供 gRPC/HTTP API 检索 Trace；支持 Tag 过滤、服务拓扑查询 | 高并发查询下响应时间退化，影响 GameDay 基线核验的实时性 |
| UI | 可视化前端 | 基于 Query API 展示 Trace 瀑布图、服务依赖图、性能散点图 | UI 加载速度直接影响故障定位效率，需纳入用户体验基线 |
实战提示： 在 GameDay 演练中，建议为 Agent 和 Collector 分别设置独立的健康检查端点（
/health），并纳入 Prometheus 告警规则。Agent 的 --processor.jaeger-binary.server-max-packet-size 参数在突发流量下极易触发丢包，是基线核验的必调参数。
2.2 数据模型：Span 与 Trace
Jaeger 的数据模型以 Span 为基本单元，多个 Span 通过父子关系或 FollowsFrom 关系组成一个 Trace。理解这两个概念是构建追踪基线的数学基础。
2.2.1 Span 结构
每个 Span 记录一次操作（如 HTTP 请求、数据库查询）的元数据，核心字段如下：
- operationName：操作名称，如
GET /api/orders。 - spanId / traceId：全局唯一标识，traceId 跨服务传递。
- parentSpanId：父 Span ID，用于构建调用树。
- startTime / duration：开始时间与耗时（微秒）。
- tags：键值对元数据，如
http.status_code=200。 - logs：时间戳事件，用于记录异常或关键状态变更。
基线核验关键指标： 在 GameDay 中，我们通常关注
duration 的 P50/P95/P99 分位值，以及 tags 中 error=true 的 Span 占比。这两个指标直接反映性能调优前后的变化。
2.2.2 Trace 生命周期
一个 Trace 从入口服务（如 API Gateway）开始，经过多个微服务，最终返回响应。Jaeger 通过 traceId 将分散在各服务的 Span 串联起来。
2.3 部署模式：All-in-one vs 生产集群
Jaeger 提供两种典型的部署模式，选择依据是环境规模、数据持久化需求和可用性要求。
| 维度 | All-in-one（单机模式） | 生产集群模式 |
|---|---|---|
| 组件部署 | Agent + Collector + Query + UI 合并为单个二进制 | 各组件独立部署，支持水平扩展 |
| 存储后端 | 内存（默认）或 Badger（本地文件） | Elasticsearch / Cassandra / Kafka 流式管道 |
| 适用场景 | 开发调试、Demo、小规模 GameDay 预演 | 生产环境、大规模 GameDay 基线核验、长期存储 |
| 高可用 | 单点故障，重启后数据丢失（内存模式） | 多副本 Collector + 有状态存储集群 |
| 性能基线 | 吞吐量 < 1000 Span/s（受限于内存） | 吞吐量可达 10万+ Span/s（依赖 ES 分片） |
GameDay 选型警告： 如果使用 All-in-one 模式进行基线核验，务必开启 Badger 持久化（
--badger.directory-key /data），否则 GameDay 演练中一旦进程重启，所有追踪基线数据将丢失，导致前后对比失效。生产集群模式下，建议为 Collector 配置 Kafka 作为缓冲层，防止存储后端抖动导致数据丢失。
2.4 生产集群架构总览
下图展示了一个典型的 Jaeger 生产集群部署架构，包含数据流路径和关键组件间的关系。该架构是后续 GameDay 演练中注入故障、验证基线的基础拓扑。
2.5 基线核验中的架构要点
在 GameDay 演练中，以下架构层面的配置直接影响基线数据的完整性和调优效果：
- 采样策略：生产环境建议使用 概率采样（如 10%）+ 自适应采样 的组合，避免全量采集导致 Collector 过载。GameDay 中可通过动态调整采样率来模拟流量突增场景。
- Collector 背压：当存储后端响应变慢时，Collector 应触发背压机制（
--collector.queue-size和--collector.num-workers）。基线核验需记录背压触发阈值和恢复时间。 - Query 缓存：Query 服务默认启用 Trace 结果缓存（
--query.cache-ttl），GameDay 中可通过清空缓存来模拟冷启动场景，验证查询性能退化程度。
实战命令速查： 启动 All-in-one 用于本地 GameDay 预演：
docker run -d --name jaeger \
-e COLLECTOR_QUEUE_SIZE=10000 \
-e COLLECTOR_NUM_WORKERS=50 \
-p 16686:16686 -p 4317:4317 -p 4318:4318 \
jaegertracing/all-in-one:1.60 \
--badger.directory-key=/data/badger \
--badger.directory-value=/data/badger