2. Jaeger 架构全景：组件与数据流详解
Jaeger 作为云原生场景下最流行的分布式追踪系统，其架构设计遵循“采集-存储-查询-可视化”的经典分层。理解各组件职责及数据流转路径，是定位慢查询、优化 SLI 口径的基础。
2.1 核心组件与职责
Jaeger 由四个主要组件构成，每个组件承担独立的可观测性职能：
| 组件 | 角色 | 核心职责 | 部署形态 |
|---|---|---|---|
| Agent | 边车代理 | 接收应用发出的 Span，批量压缩后转发给 Collector | DaemonSet / Sidecar |
| Collector | 数据管道 | 校验、聚合、写入后端存储；支持采样策略 | Deployment（无状态） |
| Query | 查询服务 | 从存储检索 Trace/Span，提供 gRPC/HTTP API | Deployment（无状态） |
| UI | 可视化 | 基于 Query API 展示 Trace 拓扑、火焰图、服务依赖 | 与 Query 同进程或独立部署 |
生产建议：Agent 推荐以 DaemonSet 模式部署在每台宿主机上，避免 Sidecar 模式带来的资源开销；Collector 和 Query 应配置 HPA，应对突发流量。
2.2 数据流全景
一条完整的 Trace 从应用发出到 UI 展示，经历以下四个阶段：
- 埋点生成：应用通过 Jaeger Client SDK 创建 Span，携带 TraceID、SpanID、ParentSpanID、OperationName、Tags、Logs。
- Agent 收集：Agent 通过 UDP 或 gRPC 接收 Span，进行协议缓冲（Thrift/Protobuf）压缩，批量发送至 Collector。
- Collector 处理：Collector 校验 Span 合法性，执行采样决策（头部采样/尾部采样），写入后端存储（Elasticsearch / Cassandra / Badger）。
- Query & UI 检索：用户通过 UI 发起查询，Query 服务从存储中按 TraceID、Service、Operation、Tags 检索，返回完整 Trace 树。
关键路径：慢查询定位的核心在于 Collector → 存储 阶段的写入延迟，以及 Query → 存储 阶段的检索延迟。这两个环节直接决定 Trace 的“端到端可见性延迟”。
2.3 组件间通信协议
Jaeger 在不同组件之间使用多种协议，理解协议差异有助于排查数据丢失或延迟问题：
| 通信链路 | 默认协议 | 序列化格式 | 端口 | 注意事项 |
|---|---|---|---|---|
| 应用 → Agent | UDP | Thrift Compact | 6831 / 6832 | UDP 可能丢包，生产建议启用 gRPC |
| Agent → Collector | gRPC | Protobuf | 14250 | 支持批量压缩，推荐生产使用 |
| Collector → 存储 | HTTP / gRPC | JSON / Protobuf | 9200 (ES) / 9042 (Cassandra) | 写入延迟直接影响 Trace 可见性 |
| Query → 存储 | HTTP / gRPC | JSON / Protobuf | 9200 (ES) / 9042 (Cassandra) | 检索性能决定 UI 响应速度 |
| UI → Query | HTTP | JSON | 16686 | 前端通过 REST API 调用 |
避坑提醒：Agent 默认使用 UDP 协议，当 Span 生成速率超过 10,000 spans/s 时，UDP 丢包率会显著上升。建议在 Collector 端开启 gRPC 接收，并将 Agent 配置为 gRPC 模式，同时增加 Collector 副本数。
2.4 采样策略与数据流影响
采样是 Jaeger 架构中控制数据量的关键机制，直接影响存储成本和慢查询定位的完整性：
- 头部采样（Head-based）：在 Trace 开始时决定是否采样，简单高效，但无法保证慢 Trace 被捕获。
- 尾部采样（Tail-based）：Collector 根据 Span 特征（如延迟 > 阈值）动态决定保留，适合慢查询定位，但增加 Collector 内存开销。
- 概率采样：按固定百分比采样，适合低流量环境。
- 速率限制采样：每秒最多采样 N 条 Trace，防止突发流量冲垮存储。
2.5 存储后端选型对比
存储是 Jaeger 架构中影响查询性能与运维复杂度的核心组件，不同场景推荐不同后端：
| 存储后端 | 适用场景 | 查询延迟 | 运维复杂度 | 数据保留策略 |
|---|---|---|---|---|
| Elasticsearch | 大规模生产环境，需要全文检索 | 中等（依赖索引优化） | 高（需管理集群、ILM） | ILM 自动轮转 |
| Cassandra | 写入密集型，需要高可用 | 低（按主键查询） | 高（需管理节点、压缩） | TTL 自动过期 |
| Badger | 单机测试、小规模演示 | 低（本地磁盘） | 低（无需额外部署） | 手动清理 |
| Kafka + ES | 超高吞吐，削峰填谷 | 中等（增加 Kafka 延迟） | 极高（需维护 Kafka 集群） | Kafka 保留 + ES ILM |
SLI 口径优化关联：在后续章节中，我们将基于 Collector 写入存储的延迟（
jaeger_collector_spans_written_latency）和 Query 检索延迟（jaeger_query_latency）来定义基础设施 SLI。存储选型直接影响这两个指标的基线值。
2.6 架构演进趋势
随着 OpenTelemetry 成为行业标准，Jaeger 架构也在持续演进：
- Agent 弱化：OpenTelemetry Collector 可替代 Jaeger Agent，统一接收多种信号（Trace/Metric/Log）。
- Collector 无状态化：通过 Kafka 作为缓冲层，Collector 可以完全无状态，便于弹性伸缩。
- Query 与 UI 合并：Jaeger v2 正在探索将 Query 和 UI 合并为单一二进制，降低部署复杂度。
- 存储抽象层：通过 gRPC 存储插件，支持更多后端（如 ClickHouse、S3）。