2. Jaeger 基础架构回顾：Agent、Collector、Query、Storage 组件及数据流

在深入质量门禁与发布异常定位之前，必须重新梳理 Jaeger 的四大核心组件及其数据流转路径。理解每个组件的职责边界与通信方式，是后续配置采样策略、排查数据丢失、优化查询性能的根基。

2.1 组件职责与部署形态

2.2 数据流全景

一条 Trace 从应用产生到 UI 展示，经历以下 5 个阶段：

1. 埋点注入： 应用通过 OpenTracing/OpenTelemetry SDK 创建 Span，携带 TraceID、SpanID、ParentSpanID。
2. Agent 接收： Agent 通过 UDP 或 gRPC 接收 Span，放入内部缓冲区，按批次压缩后发送。
3. Collector 处理： Collector 解压、校验 Span 结构，执行头采样或尾部采样策略，写入存储队列。
4. Storage 持久化： 存储后端按 TraceID 索引写入，同时建立 ServiceName、OperationName、Tags 等二级索引。
5. Query 检索： 用户通过 UI 或 API 发起查询，Query 服务从 Storage 读取 Span 并组装为完整 Trace。

2.3 关键数据流细节

2.3.1 Agent 到 Collector 的批量传输

Agent 默认每 1 秒 或缓冲区达到 1000 条 Span 时触发一次批量发送。若 Collector 不可用，Agent 会重试最多 3 次（默认），超出后丢弃 Span。此行为在发布高峰期可能导致数据丢失。

2.3.2 Collector 的采样决策点

Collector 支持两种采样模式：

• 头采样（Head Sampling）： 在 Span 进入 Collector 时立即决策，适用于低延迟场景，但无法保证完整 Trace 被采样。
• 尾部采样（Tail Sampling）： 等待 Trace 所有 Span 到达后再决策，可保证完整 Trace，但引入额外延迟与内存开销。

2.4 存储模型与索引策略

Jaeger 的存储模型以 TraceID 为主键，同时建立以下二级索引以支持快速检索：

• ServiceName + StartTime： 按服务名与时间范围查询。
• OperationName + StartTime： 按操作名与时间范围查询。
• Tags： 支持自定义标签过滤（如 error=true）。
• Duration： 按耗时范围查询慢 Trace。

以 Elasticsearch 为例，Span 文档结构如下：

{
  "traceID": "abc123",
  "spanID": "def456",
  "operationName": "HTTP GET /api/order",
  "startTime": 1710000000000000,
  "duration": 150000,
  "tags": [
    {"key": "http.status_code", "value": "500"},
    {"key": "error", "value": "true"}
  ],
  "process": {
    "serviceName": "order-service"
  }
}

2.5 组件通信协议汇总