2. Jaeger 基础架构：组件与数据流

在事故响应场景中，理解 Jaeger 的组件拓扑和数据流转路径，是快速定位采集失败、数据延迟、查询超时等故障的前提。Jaeger 采用微服务架构，核心组件包括 Agent、Collector、Query 和 UI，它们通过标准协议协作完成从数据采集到可视化展示的全链路。

2.1 核心组件与职责

2.2 数据流全景

一条完整的 Trace 从业务应用发出到 UI 展示，经历以下 5 个阶段：

1. 应用端生成 Span：通过 Jaeger Client SDK（Java/Go/Python/Node.js 等）在服务调用边界创建 Span，携带 TraceID、SpanID、ParentSpanID、OperationName、Tags、Logs。
2. Agent 接收与批处理：Agent 通过 Thrift 协议（UDP）接收 Span，在内存中按批次压缩，使用 gRPC 或 Thrift（TCP）转发给 Collector。
3. Collector 校验与存储：Collector 对 Span 进行 schema 校验、采样判断、服务名归一化，然后写入后端存储（Cassandra / Elasticsearch / Badger）。
4. Query 索引与检索：Query 从存储层读取索引（服务名、Operation、Tags），根据用户查询条件组装完整的 Trace 树。
5. UI 渲染：UI 通过 gRPC Gateway 调用 Query 的 HTTP API，将 JSON 格式的 Trace 数据渲染为时序图、火焰图或依赖图。

2.3 组件间通信协议

不同组件之间的通信协议决定了数据格式、传输可靠性和故障隔离边界。下表总结了关键协议及其在事故场景中的影响：

2.4 数据流中的关键故障点

基于上述架构，事故响应团队在变更窗口应重点监控以下 4 个故障点：

• Agent 端 UDP 丢包：使用 jaeger_agent_thrift_udp_server_packets_dropped_total 指标监控，若持续增长说明 Agent 处理能力不足或网络拥塞。
• Collector 队列积压：监控 jaeger_collector_queue_length，当队列长度超过阈值（如 10000）时，说明 Collector 消费速度跟不上生产速度。
• 存储写入延迟：Elasticsearch 场景下监控 jaeger_collector_spans_written_latency，若 P99 超过 500ms，需排查 ES 集群负载或索引性能。
• Query 查询超时：监控 jaeger_query_trace_latency，若 P99 超过 3s，通常由存储层慢查询或 Query 资源不足引起。

2.5 组件部署拓扑与变更窗口影响

在生产环境中，Jaeger 组件的部署拓扑直接影响变更窗口的风险面。以下是两种典型部署模式及其事故响应差异：