2. Jaeger架构全景：Agent、Collector、Query、Storage四大组件的职责与数据流关系
在分布式追踪的MTTR复盘场景中，理解Jaeger的组件拓扑是定位故障路径的前提。Jaeger采用解耦的管道架构，将数据采集、处理、存储与查询分离为四个独立组件。每个组件在故障链中扮演不同角色，任何一个组件的异常都会导致追踪数据丢失或查询延迟，直接影响MTTR的准确性。
2.1 四大组件核心职责
| 组件 | 进程角色 | 核心职责 | MTTR关联故障点 |
|---|---|---|---|
| Agent | 边车/DaemonSet | 接收应用Span数据，批量压缩转发至Collector | Agent崩溃导致Span丢失；端口冲突 |
| Collector | 无状态服务 | 校验、索引、写入Storage；支持采样策略下发 | Collector OOM；写入Storage超时 |
| Query | 无状态服务 | 提供API/UI查询；从Storage读取Span并组装Trace | Query响应慢；Storage连接池耗尽 |
| Storage | 有状态后端 | 持久化Span数据；支持Elasticsearch/Cassandra/Badger | 磁盘IO瓶颈；索引膨胀；集群脑裂 |
MTTR复盘提示： 在故障排查时，优先检查Collector与Storage之间的写入延迟。如果Collector日志出现“写入超时”或“bulk拒绝”，说明Storage层已成为瓶颈，此时Query查询也会同步变慢，形成“假性全链路故障”。
2.2 数据流关系与组件交互
Jaeger的数据流遵循“应用端 → Agent → Collector → Storage → Query”的单向管道模型。理解每个跳转点的协议与超时配置，是定位数据断流的关键。
- 应用 → Agent（UDP/gRPC）：应用通过Jaeger Client SDK将Span发送到本地Agent。默认使用UDP（端口6831/6832），存在丢包风险；生产环境建议切换为gRPC（端口14250）。
- Agent → Collector（gRPC）：Agent将批量压缩后的Span通过gRPC发送至Collector。此阶段若Collector不可达，Agent会缓存并重试，但缓存有上限。
- Collector → Storage（写入API）：Collector将校验后的Span写入后端存储。对于Elasticsearch，使用Bulk API批量写入；写入失败时Collector会重试，但可能造成数据重复。
- Query → Storage（读取API）：Query服务接收用户查询请求，从Storage读取Span并还原Trace拓扑。查询超时通常由Storage响应慢或索引未优化导致。
2.3 组件部署拓扑与故障隔离
在分布式部署场景下，组件间的网络拓扑直接影响故障隔离边界。以下列出三种典型部署模式及其MTTR影响：
| 部署模式 | Agent位置 | Collector部署 | 故障隔离能力 | MTTR影响 |
|---|---|---|---|---|
| Sidecar模式 | 每个Pod一个Agent | 独立Deployment | Agent故障仅影响单个Pod | 低（局部影响） |
| DaemonSet模式 | 每个Node一个Agent | 独立Deployment | Agent故障影响整节点所有Pod | 中（节点级影响） |
| Agentless模式 | 无Agent | 直接接收应用Span | Collector直接暴露，故障影响全局 | 高（全局影响） |
MTTR复盘避坑： 在Agentless模式下，如果Collector发生OOM重启，所有应用服务的Span将直接丢失，无法重试。建议生产环境至少部署2个Collector副本，并配置Agent端gRPC负载均衡。
2.4 组件间通信协议与端口清单
故障排查时，端口连通性检查是第一道防线。以下列出Jaeger组件间默认通信端口及协议：
| 通信方向 | 协议 | 默认端口 | MTTR检查项 |
|---|---|---|---|
| 应用 → Agent | UDP / gRPC | 6831(UDP) / 14250(gRPC) | UDP丢包率；gRPC连接超时 |
| Agent → Collector | gRPC | 14250 | Collector服务发现；TLS证书 |
| Collector → Storage | HTTP / 原生协议 | 9200(ES) / 9042(Cassandra) | Bulk队列积压；写入延迟P99 |
| Query → Storage | HTTP / 原生协议 | 9200(ES) / 9042(Cassandra) | 查询超时；索引状态 |
| Query → UI | HTTP | 16686 | 前端资源加载；API响应码 |
2.5 组件故障排查速查表
在MTTR复盘过程中，以下速查表可帮助快速定位故障组件：
| 故障现象 | 可能故障组件 | 排查命令/日志关键字 | 恢复动作 |
|---|---|---|---|
| UI页面无数据 | Query / Storage | curl localhost:16686/api/traces |
检查Query日志；检查ES索引状态 |
| 部分服务无追踪 | Agent / 网络 | netstat -an | grep 6831 |
重启Agent；检查防火墙规则 |
| Collector日志报错 | Collector / Storage | level=error msg="写入失败" |
扩容Collector；检查Storage磁盘 |
| 查询响应慢 | Storage / Query | ES慢查询日志 |
优化索引；增加Query副本 |
MTTR复盘最佳实践： 建议为每个Jaeger组件配置独立的健康检查端点（/health），并集成到Prometheus告警中。当Collector的“写入延迟P99”超过500ms时，立即触发告警，避免故障扩散到Query层。