Tempo 架构速览：核心组件、数据流与查询路径
在深入分析查询延迟对 MTTR 的影响之前，必须先理解 Grafana Tempo 的架构。Tempo 采用微服务架构，通过解耦写入、存储与查询路径来支撑高基数、高吞吐的 Trace 数据。本章将拆解其核心组件、数据写入流程与查询路径，为后续延迟分析奠定基础。
2.1 核心组件与职责
Tempo 由四个主要组件构成，每个组件承担明确的职责，并通过 gRPC/HTTP 协议协作。
| 组件 | 核心职责 | 关键特征 |
|---|---|---|
| Distributor | 接收 Trace 数据，验证并分发 | 无状态、可水平扩展；负责 哈希路由 |
| Ingester | 临时存储与批量写入后端 | 有状态、带生命周期管理；负责 Flush 到对象存储 |
| Querier | 处理查询请求，合并结果 | 无状态、支持缓存；同时查询 Ingester 与后端存储 |
| Compactor | 合并与去重后端存储中的块 | 后台异步运行；优化存储效率与查询性能 |
架构要点：Distributor 和 Querier 是无状态组件，适合快速弹性伸缩；Ingester 是有状态组件，其生命周期管理直接影响数据可见性延迟。
2.2 数据流：从 Trace 接收到持久化
Trace 数据从应用端发出到最终持久化，经历以下关键步骤：
- 应用端推送：应用通过 OpenTelemetry SDK 或 Jaeger Agent 将 Trace 数据以 Batch 形式发送到 Distributor。
- Distributor 验证与路由：Distributor 对 Span 进行基本校验（如 TraceID 格式），然后根据 TraceID 的哈希值将数据路由到对应的 Ingester 实例。
- Ingester 接收与缓冲：Ingester 将接收到的 Span 写入内存中的 Block，并定期（默认 30s）将完成的 Block 刷新（Flush）到后端对象存储（如 S3、GCS、Azure Blob）。
- Compactor 后台合并：Compactor 扫描后端存储中的小 Block，将其合并为更大的 Block，并执行去重与索引优化。
延迟关键点：Ingester 的 Flush 周期与 Compactor 的合并周期共同决定了“数据写入到可查询”的延迟窗口。默认配置下，数据通常在 30s–2min 内变为可查询。
2.3 查询路径：从 TraceID 到完整 Trace
查询路径与写入路径解耦，Querier 作为查询入口，需要同时访问 Ingester（热数据）和后端存储（冷数据）。
- 步骤 1：用户通过 Grafana 或 API 发起查询（TraceID 查询或 Service/Operation 搜索）。
- 步骤 2：Querier 将请求转发到所有 Ingester 实例，查询仍在内存中的热数据。
- 步骤 3：Querier 同时向后端对象存储发起查询，检索已持久化的 Block。
- 步骤 4：Querier 合并来自 Ingester 和存储的结果，去重后返回完整 Trace。
延迟陷阱：如果 Querier 需要扫描大量小 Block（Compactor 未及时合并），或 Ingester 返回超时，查询延迟会显著增加，直接影响 MTTR。
2.4 组件协作与延迟敏感点
下表总结了各组件在查询延迟链路上的关键影响点：
| 组件 | 延迟贡献因素 | 对 MTTR 的影响 |
|---|---|---|
| Distributor | 数据验证、哈希路由、网络 I/O | 低（写入路径，不影响查询） |
| Ingester | 内存 Block 查询响应时间、Flush 延迟 | 中（热数据查询必须等待 Ingester 响应） |
| Querier | 并发查询能力、缓存命中率、结果合并开销 | 高（直接决定查询响应时间） |
| Compactor | Block 合并效率、索引优化程度 | 中（影响冷数据查询效率） |
| 对象存储 | 读取延迟、Block 数量、请求并发 | 高（冷数据查询的主要瓶颈） |
架构启示：在排查 MTTR 问题时，应优先关注 Querier 的查询计划与对象存储的 Block 布局。Compactor 的合并策略直接影响冷数据查询需要扫描的 Block 数量，是优化查询延迟的重要杠杆。