2. Tempo 架构概览：核心组件、数据流与角色职责

在深入存储调优之前，必须先理解 Tempo 的架构骨架。Tempo 采用微服务架构，核心组件各司其职，通过异步管道协同完成从数据接收到查询响应的全流程。本章将拆解每个组件的职责、数据流转路径以及它们在性能调优中的关键角色。

2.1 核心组件与角色职责

Tempo 由四个主要组件构成：Distributor、Ingester、Querier 和 Compactor。每个组件均可独立水平扩展，这也是 Tempo 能够支撑大规模分布式追踪场景的基础。

2.2 数据流全景：从接收到查询

一条 Trace 数据从被采集到最终可被查询，经历四个阶段。理解这个流程是定位性能瓶颈的前提。

1. 接收与分发： 应用通过 OpenTelemetry SDK 或 Jaeger Agent 将 Trace 发送至 Distributor。Distributor 根据 TraceID 进行一致性哈希，将数据路由到对应的 Ingester 实例。
2. 写入与缓冲： Ingester 将接收到的 Span 数据暂存于内存中，并定期 Flush 到后端存储（如对象存储或 Cassandra）。内存中的数据同时用于近期查询。
3. 合并与优化： Compactor 异步扫描存储后端，将多个小文件合并为更大的块，减少存储碎片并优化索引结构。
4. 查询与检索： Querier 接收用户查询，先向所有 Ingester 发起请求获取内存中的最新数据，再扫描存储后端中的历史数据，最终合并结果返回。

2.3 组件间通信与关键交互

组件之间的通信方式直接影响延迟和可靠性。Tempo 主要使用 gRPC 进行内部通信，并依赖一致性哈希实现数据路由。

• Distributor ↔ Ingester： 使用 gRPC 流式传输，Distributor 根据 TraceID 的哈希值将数据发送到对应的 Ingester 副本。此环节的瓶颈通常出现在 Distributor 的 gRPC 连接池大小和 Ingester 的接收队列深度。
• Ingester ↔ 存储后端： Ingester 将数据以 Parquet 格式写入对象存储（推荐）或 Cassandra。写入频率由 ingester.flush-check-period 和 ingester.trace-idle-period 控制。
• Querier ↔ Ingester： 查询时，Querier 并行向所有 Ingester 发起 gRPC 请求，获取内存中的最新数据。如果 Ingester 响应慢，会直接拖累查询 P99 延迟。
• Compactor ↔ 存储后端： Compactor 定期扫描存储桶中的小文件，合并后重新写入。合并后的块越大，Querier 扫描时的索引效率越高。

2.4 数据模型与存储结构

Tempo 将 Trace 数据组织为 Block 和 Index 两层结构。理解这一模型是调优存储性能的前提。

2.5 关键配置参数速查

以下参数是值班台调优中最常触及的配置项，直接影响组件行为。

2.6 值班台实战视角：组件健康检查清单

在值班台日常巡检中，建议关注以下指标，快速定位组件级问题。

• Distributor： 检查 tempo_distributor_bytes_received_total 是否平稳，如果出现陡降，可能是上游 SDK 或网络问题。
• Ingester： 监控 tempo_ingester_live_traces 和 process_resident_memory_bytes。如果内存持续增长且不回落，说明 Flush 阻塞。
• Compactor： 观察 tempo_compactor_blocks_combined_total 和 tempo_compactor_errors_total。错误数突增通常意味着存储后端限流或权限问题。
• Querier： 关注 tempo_querier_query_duration_seconds 的 P99 值。如果超过 5 秒，优先排查 Ingester 响应时间和存储索引效率。