Tempo 3.1 介绍与选型指南

Tempo 3.1 介绍与选型指南：官方资料溯源的 Grafana 系分布式追踪后端架构（读写分离与对象存储）、TraceQL 查询语言与 trace-derived metrics、vParquet5 存储格式、快速上手与适用限制，以及与 Jaeger、Zipkin、SigNoz、Elastic APM 的量化选型对比，并说明其与 Grafana LGTM 栈的集成关系。

TempoTempo链路追踪2026/10/19

Tempo 3.1 介绍与选型指南

目标：基于官方公开资料（GitHub 官方仓库 grafana/tempo 发行页与 README、Grafana 官方文档与博客）溯源介绍 Grafana Tempo 的定位、架构、功能与选型对比，本文不做本地安装与运行实测，所有版本与数据均标注来源与查询日期 2026-10-19。

一、信息基准

1.1 查询说明

  • 查询日期：2026-10-19。
  • 信息获取方式：纯官方资料溯源（github.com/grafana/tempo 发行页与 README、grafana.com 官方文档与官方博客），本文不做本地安装与运行实测。
  • 版本结论：本次介绍的版本为 Grafana Tempo v3.1.0（2026-09-29 发布），为当前最新稳定 minor；3.0 线最新补丁为 v3.0.4（2026-10-16），2.x 线最新补丁为 v2.10.8（2026-08-13）。特别说明：Tempo 当前稳定线已是 3.x（v3.0.0 于 2026-05-28 打标、官方博客 2026-06-01 宣布 GA），本文按实查结果以 3.1 为介绍基准。

1.2 版本依据

项目实查结果（2026-10-19）来源
最新稳定 minorv3.1.0（2026-09-29）github.com/grafana/tempo/releases
3.0 线最新补丁v3.0.4（2026-10-16）github.com/grafana/tempo/releases
3.0 GAv3.0.0 标签 2026-05-28；官方博客发布于 2026-06-01github.com/grafana/tempo/releases/tag/v3.0.0；grafana.com/blog/tempo-3-0-release-all-the-latest-features/
2.x 线末版补丁v2.10.8（2026-08-13）github.com/grafana/tempo/releases
代码仓库grafana/tempogithub.com/grafana/tempo
开源许可AGPL-3.0-only（Apache-2.0 例外见 LICENSING.md）仓库 README License 段与 LICENSE 文件
社区活跃度5.5k stars（shields.io 实查）shields.io/github/stars/grafana/tempo

1.3 官方来源清单

来源地址
源码仓库https://github.com/grafana/tempo
官方文档https://grafana.com/docs/tempo/latest/
快速上手https://grafana.com/docs/tempo/latest/getting-started/
v3.0 发行说明https://grafana.com/docs/tempo/latest/release-notes/v3-0/
v3.1.0 发行说明https://github.com/grafana/tempo/releases/tag/v3.1.0
Tempo 3.0 官方博客https://grafana.com/blog/tempo-3-0-release-all-the-latest-features/

二、软件概述

本文介绍的是 Grafana Tempo v3.1.0（2026-09-29 发布，AGPL-3.0-only 开源）。

Grafana Tempo 是一个开源、易用、面向大规模场景的分布式追踪后端（tracing backend）。官方 README 概括其三个核心特征：成本高效——只需对象存储（S3、GCS、Azure Blob 或本地磁盘）即可运行，无需专门数据库；易运维——接收 Jaeger、Zipkin、Kafka 与 OpenTelemetry 等多种协议格式的批量数据，缓冲后写入对象存储；深度集成——与 Grafana、Prometheus、Loki 紧密协作（官方 README 实查）。

Tempo 由 Grafana Labs 主导，是 Grafana 官方可观测组合 LGTM 栈（Loki 日志、Grafana 可视化、Tempo 追踪、Mimir 指标）中的追踪组件：Loki/Grafana/Tempo/Mimir 四件套均以 AGPL-3.0 发布，共享相似的对象存储架构与部署模式。Tempo 的接收层、线协议与存储格式直接基于 OpenTelemetry 的标准与代码构建（官方 README「OpenTelemetry」一节实查）。

三、核心架构

3.1 存储与部署形态

  • 对象存储为唯一持久层：Tempo 将 trace 数据以块（block）形式写入 S3/GCS/Azure 或本地磁盘，单二进制即可启动，这是其「廉价、易运维」定位的基础（官方 README 实查）。
  • 单进程 all 模式与微服务模式：all 模式下一个进程包含全部功能模块（distributor、live-store、block-builder、querier、query-frontend、compactor 等）；微服务模式按角色拆分横向扩展（官方仓库 example 目录提供 Docker Compose、Helm、Jsonnet 三类部署示例）。
  • 3.0 新架构（读写分离）：Tempo 3.0 用新写入架构取代旧 ingester——微服务模式下引入 Kafka 兼容系统作为写入缓冲，读路径与写路径彻底分离，官方称由此获得更高的可靠性与可扩展性并降低 TCO（官方发行说明与博客实查）。

3.2 数据流

数据经 distributor 接收（支持 OTLP、Jaeger、Zipkin、Kafka 等格式），缓冲后由写入路径构建为块写入对象存储；查询经 query-frontend 拆分并分发至 querier 从对象存储检索；compactor 负责块合并与压缩，vParquet5 为 3.1 起新写入块的默认存储格式（官方发行说明实查）。

3.3 查询语言与工具组件

组件说明（官方 README/文档口径）
TraceQL受 LogQL/PromQL 启发的 trace 专用查询语言
TraceQL metrics从 trace 派生指标并按任意维度聚合，3.0 起 GA
tempo-cli官方命令行工具（配置迁移、数据操作、redact 等）
tempo-vulture一致性校验工具：写入 trace 再多路径读回比对

四、功能特性

4.1 广泛的接收兼容性

官方 README 明确：Tempo 兼容 Jaeger、Zipkin、Kafka 与 OpenTelemetry 四类输入，接收层、线协议与存储格式直接复用 OpenTelemetry 标准组件，已有 OTel 埋点可以近乎零改造接入。

4.2 TraceQL 与 trace 派生指标

TraceQL 支持按属性定位具体 trace 与结构化检索；TraceQL metrics 在 3.0 转 GA，可对任意 TraceQL 查询结果按维度做运行时聚合，直接从追踪数据产出 RED 类指标，3.1 又加入 metrics 算术运算与采样感知外推（sampling-aware extrapolation），对采样环境的指标估算更准确（v3.1.0 发行说明实查）。

4.3 数据治理与性能剖析

  • Trace redaction：3.0 引入按查询隐藏敏感 trace 数据的 CLI 命令与 API；3.1 扩展为基于查询的 redaction 并支持时间窗口分片执行（官方发行说明实查）。
  • Span profiling：3.0 起通过 otelpyroscope 将 pprof 性能剖析数据关联到 trace span（官方发行说明实查）。
  • metrics-generator 增强：按标签的基数限制、服务图过滤、面向采样环境的 span multiplier 等（官方 v3.0 发行说明实查）。

4.4 与 Grafana 生态的联动

Tempo 深度集成 Grafana：TraceQL 编辑器、Traces Drilldown（原 Explore Traces，免写查询的点选式 trace 分析应用）、日志-追踪互链等能力都在 Grafana 内呈现（官方 README 实查）。这也是「LGTM 栈一体化采购/自建」路径的核心卖点。

五、快速上手

以下步骤转述自官方 README 与官方文档，本文不做本地实测。

5.1 获取与运行

官方 README「Getting started with Tempo」指向 https://grafana.com/docs/tempo/latest/getting-started/ ，并在仓库 example/ 目录提供 Docker Compose、Helm、Jsonnet 三套部署示例（github.com/grafana/tempo/tree/main/example）。以 Docker Compose 为例，使用官方镜像 grafana/tempo，配置对象存储（本地磁盘即可起步）与接收端口后启动单进程 all 模式。

5.2 写入数据

Tempo 原生接收 OpenTelemetry 协议：将 OTLP exporter 的 endpoint 指向 Tempo 的 OTLP 接收端口（4317 gRPC / 4318 HTTP）即可写入；官方集成指南（https://grafana.com/docs/tempo/latest/guides/instrumentation/ ）给出各语言 OTel 埋点对接 Tempo 的示例。

5.3 查询验证

在 Grafana 中添加 Tempo 数据源后，可用 TraceQL（如按 service.name 过滤）查询 trace，或使用 Traces Drilldown 做 RED 指标浏览；也可以通过 Tempo HTTP API 直接检索（官方文档转述）。

六、适用场景与限制

6.1 适用场景

  • 大规模、成本敏感的追踪后端：只需对象存储，无需运维专门的查询数据库，存储成本随 S3 类服务线性可算。
  • 已采用 Grafana 可观测体系（Prometheus/Loki/Grafana）的团队：LGTM 栈一体化，日志-指标-追踪互链体验完整。
  • OpenTelemetry 标准化路线：接收层即 OTel，避免厂商协议锁定。
  • 需要「从 trace 生成指标」的团队：TraceQL metrics GA 后可直接对追踪数据做运行时聚合与告警。

6.2 限制与注意事项

  • AGPL-3.0 许可：对「修改后作为网络服务提供」的场景有开源义务，商业合规需先过法务（README License 段实查）。
  • 3.0 是带破坏性变更的大版本：官方明确旧 ingester、legacy overrides、v2 块、OpenCensus 等需按迁移指南处理，升级前必须核对（v3.0 发行说明与迁移指南链接实查）。
  • 无内置 UI：查询与可视化依赖 Grafana（UI 相关 issue 需提到 grafana/grafana 仓库）。
  • 微服务模式引入 Kafka 兼容缓冲后，组件数量与运维面大于单机方案；小规模团队建议从 all 模式起步。

七、同类选型对比

7.1 候选概览

工具定位开源许可
Grafana Tempo 3.1对象存储型高规模追踪后端（LGTM 栈）AGPL-3.0-only
JaegerCNCF 毕业的原生分布式追踪平台Apache-2.0（仓库 LICENSE 实查）
Zipkin老牌轻量分布式追踪系统Apache-2.0（shields 徽章实查）
SigNoz开源一体化可观测（trace+metrics+logs）MIT 为主（ee/ 企业目录另按 ee/LICENSE，仓库 LICENSE 实查）
Elastic APMElastic Stack 内的 APM/追踪方案Apache-2.0 为主（x-pack 目录为 Elastic License，仓库 LICENSE.txt 实查）

7.2 量化对比（2026-10-19 实查）

维度Tempo 3.1JaegerZipkinSigNozElastic APM
GitHub stars5.5k（grafana/tempo）23k（jaegertracing/jaeger）17k（openzipkin/zipkin）32k（SigNoz/signoz）1.3k（elastic/apm-server）
最近发版v3.1.0（2026-09-29）v2.22.0v3.6.1v0.146.0apm-server v9.5.5
许可证AGPL-3.0-onlyApache-2.0Apache-2.0MIT 为主 + EEApache-2.0 + Elastic License
存储依赖仅对象存储（S3/GCS/Azure/本地盘）支持 Cassandra/Kafka/ES 等多后端内嵌/ES、Cassandra、MySQL 等ClickHouse + PostgreSQLElasticsearch
查询语言TraceQL + UIJaeger UI/APIZipkin UI/API查询 UI（ClickHouse 底座）Kibana/ES DSL
生态归属Grafana LGTM 栈CNCF 毕业项目独立社区SigNoz Inc.Elastic

（stars 与版本取自各项目 GitHub 仓库/releases 与 shields.io 实查；许可证取自各仓库 LICENSE 文件实查。）

7.3 选型建议

  • 已有 Grafana + Prometheus/Loki 体系、追求大规模低成本存储的团队，Tempo 与现有栈咬合最紧，对象存储架构也最省运维，参见《Jaeger 2.22 介绍与选型指南》对比原生 CNCF 方案。
  • 追踪协议历史包袱重（Jaeger/Zipkin 客户端存量）的团队，Tempo 与 Jaeger 均可平滑接收；若希望追踪后端本身有独立 UI、不绑 Grafana，Jaeger 更合适。
  • 需要「追踪+指标+日志+仪表盘」一个开源仓库全包的中小团队，SigNoz 的一体化形态更省心，代价是定制深度不如各专精组件组合。
  • 已自建 Elasticsearch 且深度使用 Kibana 的团队，Elastic APM 可以复用现有存储与安全体系；注意 x-pack 商业模块的许可边界。
  • 历史最久、组件最轻的 Zipkin 适合轻量场景与教学，但新特性（派生指标、TraceQL 类查询语言）已明显落后于 Tempo/Jaeger 的演进节奏；如需了解其配置体系可参考《Zipkin 配置参数详解》。

八、参考链接