Grafana Tempo 完全指南高吞吐、低成本、与 Grafana 深度集成的分布式追踪后端【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempoGrafana Tempo 是一个开源、易用、可支撑大规模数据量的分布式追踪后端以仅需对象存储即可运行的低成本架构著称并与 Grafana、Prometheus、Loki 深度集成。本文以仓库根目录的 README.md 为主线结合仓库源码、部署示例与官方文档系统讲解 Tempo 的核心价值、TraceQL 查询语言与 TraceQL metrics、多协议数据接入与多存储后端架构以及一键部署方案与配套工具链帮助读者快速上手并理解其底层实现。分布式追踪的业务价值为什么需要 Tempo分布式追踪帮助团队快速定位性能问题、理解请求在多个服务之间的流转路径。当服务数量增多、调用链变长时传统日志与指标难以回答一次请求到底经历了什么这一问题而追踪数据恰好补上了这块拼图。Tempo 官方文档强调借助追踪数据可以做比看指标更深入的排查例如对服务故障进行根因分析RCA。README.md 指出Tempo 内置的Traces Drilldown UI前身为 Explore Traces通过无查询式queryless的友好界面让团队无需编写复杂查询即可发现慢请求、错误调用与延迟瓶颈。其关键特性包括直观的 Trace 分析通过简单的点击交互即可发现慢或易错的 traceRED 指标总览基于 Rate、Errors、Duration 三类指标突出性能问题自动化对比自动比较 trace 并识别可疑属性简化可视化无需构造 TraceQL 查询即可获得丰富的可视化数据。追踪数据本身具有树形结构——包含根节点、分支与叶子节点任意位置携带键值key/value元数据与时间戳。这种结构决定了它既能回答某个服务是否变慢也能回答是哪一次具体调用、哪个属性导致了变慢。这正是 TraceQL 这类专为 trace 设计的查询语言发挥价值的场景。TraceQLtraces-first 查询语言设计理念与语法来源Tempo 实现了 TraceQL一门受 LogQL 与 PromQL 启发、以 trace 为第一公民的查询语言。官方文档明确说明TraceQL 在语法与语义上尽可能与 PromQL、LogQL 保持一致docs/sources/tempo/traceql/_index.md因此熟悉 Prometheus 或 Loki 查询的用户可以快速迁移思维PromQL面向指标metrics回答现在系统状态如何LogQL面向日志logs回答发生了什么TraceQL面向 tracespans回答一次请求的完整链路与关键属性是什么。TraceQL 支持精准的定向查询targeted queries也支持由 UI 驱动的富查询分析rich UI-driven analyses。它可以对 trace 的任意属性做筛选——服务名、span 名、持续时间、任意 key/value 标签甚至可以组合多个条件进行复杂的链路过滤。查询入口命令行与 GrafanaTraceQL 的使用入口有两类Grafana 查询编辑器与查询构造器在 Grafana 的 Tempo 数据源Explore中直接书写或可视化构造 TraceQL 查询命令行通过 cmd/tempo-cli 提供的命令直接对后端存储发起查询例如cmd-query-search.go支持从命令行执行 TraceQL 搜索。此外对于不想编写 TraceQL 的用户Traces Drilldown 应用提供了无查询式的分析体验而想要在 Grafana 中编写 TraceQL 的读者可参考 query-editor 文档。前置条件Parquet 列式存储TraceQL 依赖 Apache Parquet 列式存储格式这也是 Tempo 的默认 block 格式。官方文档明确指出TraceQL requires the Parquet columnar format, which is the default block format for Tempodocs/sources/tempo/traceql/_index.md。仓库中 tempodb/encoding/vparquet5、tempodb/encoding/vparquet4、tempodb/encoding/vparquet3 等目录对应不同版本的 Parquet 编码实现也印证了 Tempo 围绕 Parquet 构建查询引擎的架构。引擎实现从源码看 TraceQL 的执行路径在源码层面TraceQL 的解析与执行集中在 pkg/traceql 包中。核心入口是 engine.goCompile(query, opts...)解析并编译 TraceQL 查询返回 AST 根表达式RootExpr、流水线Pipeline、spanset 过滤函数与取数请求FetchSpansRequestCompileFetchSpanRequests支持将一条查询拆分为多个子查询这为数学表达式多子查询类 metrics 查询提供了支撑ExecuteSearch真正执行搜索通过 fetcher 逐层拉取并过滤 spanset。pkg/traceql包还包含完整的语言基础设施lexer.go、parse.go、ast.go、ast_execute.go、ast_metrics.go分别负责词法分析、语法解析、AST 构建、执行与 metrics 语义expr.y/expr.y.go是 goyacc 语法定义enum_operators.go、enum_statics.go、enum_aggregates.go定义了运算符、静态值与聚合函数枚举。整套实现说明 TraceQL 是一门结构完整、可独立编译执行的正规查询语言而非简单的字符串匹配。TraceQL metrics用 trace 生成指标用指标回答哪里慢了README.md 将TraceQL metrics标记为 Grafana Tempo 的实验性experimental特性但它是 Tempo 最具差异化的能力之一。其核心思想是对 trace 查询结果施加一个函数从而从 trace 生成指标。这与 LogQL metric queries 从日志生成指标的方式异曲同工——任何一条已有的 TraceQL 查询都可以按 trace 中任意维度做临时聚合ad hoc aggregation。能力画像对任意 TraceQL 查询结果应用聚合函数如count、min、max、sum、avg、quantile等见 ast_metrics.go 与 engine_metrics.go按 trace 中携带的任意维度服务、span 名、自定义标签等进行聚合无需预先定义指标让指标驱动与trace 驱动两种排查路径打通先看指标发现异常再下钻到具体 trace。与 TraceQL metrics 互补的是 Tempo 的metrics-generator模块modules/generator它能将 trace 聚合成 service graphs 与 span metrics并配合 exemplars实现从 API 延迟指标尖峰跳转到贡献该尖峰的 trace。官方文档在 TraceQL 中专门描述了这条路径metrics-generator 先将 trace 聚合为服务图与 span 指标exemplars 则充当指标与 trace 之间的桥梁。配置示例在单机部署中启用 metrics 处理在 example/docker-compose/single-binary/tempo.yaml 中可以看到完整的 metrics-generator 配置metrics_generator: registry: external_labels: source: tempo cluster: docker-compose storage: path: /var/tempo/generator/wal remote_write: - url: http://prometheus:9090/api/v1/write send_exemplars: true配套的overrides段启用处理器并开启原生直方图overrides: defaults: metrics_generator: processors: [span-metrics, service-graphs] generate_native_histograms: both其中processors字段取值在源码中有明确枚举modules/generator/processor/processor_names.go常用的是span-metricsspan 指标与service-graphs服务调用图generate_native_histograms可设为both同时生成原生与经典直方图。remote_write指向 Prometheus 的/api/v1/write端点并开启send_exemplars从而让 Prometheus 侧能借助 exemplar 跳转到具体 trace。兼容性与存储架构只需对象存储的廉价后端协议兼容Jaeger、Zipkin、Kafka、OpenTelemetryREADME.md 明确声明 Tempo 兼容 Jaeger、Zipkin、Kafka 与 OpenTelemetry 四种数据接入方式它可以按上述任一格式摄取批次ingest batches缓冲后再写入 Azure、GCS、S3 或本地磁盘。这使得 Tempo 作为后端即插即用已有 OpenTelemetry 或 Jaeger 埋点的应用无需改造成本即可接入。在源码层面接收器receiver实现在 modules/distributor/receiver 中直接复用了 OpenTelemetry Collector 生态的接收器组件shim.gootlpreceiverOTLP gRPC / HTTPjaegerreceiverJaeger 协议zipkinreceiverZipkin 协议kafkareceiverKafka 消息中的 trace 数据。shim.go中还通过 usagestats 分别统计receiver_enabled_otlp、receiver_enabled_jaeger、receiver_enabled_zipkin、receiver_enabled_kafka侧面印证了这四类接入方式的正式支持。存储后端Azure、GCS、S3、本地磁盘Tempo 的块存储block storage抽象位于 tempodb/backend为以下后端提供统一接口azureAzure Blob StoragegcsGoogle Cloud Storages3AWS S3 及兼容对象存储local本地磁盘。由于只依赖对象存储Tempo 无需自建数据库或专用存储集群这构成了它robust、cheap、easy to operate健壮、廉价、易运维的架构基础。写入链路为接收器 → 缓冲 → 对象存储读取链路则由 querier/query-frontend 按 block 元数据定位并查询 Parquet 列数据。单机模式的存储配置在 example/docker-compose/single-binary/tempo.yaml 中本地磁盘后端的配置非常简洁storage: trace: backend: local wal: path: /var/tempo/wal # where to store the wal locally local: path: /var/tempo/blockswal目录存放预写日志local.path存放最终落盘的 Parquet block。生产环境将backend切换为s3/gcs/azure并补充对应凭据配置即可。快速开始Docker Compose 一键部署全栈单机示例拓扑仓库提供了多套部署示例example/docker-composeDocker Compose、example/helmHelm、example/tkJsonnet。其中 example/docker-compose/single-binary 演示了最轻量的全栈体验docker-compose.yaml中包含以下服务tempo以-targetall单二进制运行全部模块-config.file/etc/tempo.yaml启动暴露3200Tempo API/查询端口、4317OTLP gRPC、4318OTLP HTTPk6-tracing持续产生模拟 trace 的压测客户端向 alloy 的4317端口推送 OTLP 数据alloyGrafana Alloy 数据采集器作为 OTLP 数据入口再转发至 Tempoprometheus启用 remote-write-receiver、exemplar-storage 与 native-histograms接收 metrics-generator 的 remote writegrafana预置 Tempo/Prometheus 数据源与 dashboard并开启traceqlEditor、metricsSummary功能开关便于直接体验 TraceQLvultureTempo 的一致性校验工具详见下文。关键启动参数与数据流Tempo 容器以-targetall运行全部模块distributor、ingester、querier、query-frontend、metrics-generator 等合一对应的tempo.yaml开启stream_over_http_enabled: true允许 HTTP 流式读取搜索结果与query_frontend.mcp_server.enabled: true。数据流向为k6-tracing (OTLP) → alloy (4317) → tempo distributor (4317/4318 OTLP) ↓ 缓冲与写块 local 磁盘/var/tempo/blocks ↓ metrics-generator Prometheus remote write9090启动该示例只需在目录下执行docker compose up -d随后访问http://localhost:3000Grafana体验 TraceQL 查询与 Traces Drilldown访问http://localhost:3200Tempo 查询 API。配套工具tempo-vulture 与 tempo-cliREADME.md 还介绍了两个与 Tempo 生态强相关的官方工具tempo-vulture一致性校验工具tempo-vulture秃鹫延续 Tempo 的鸟类命名传统用于持续向 Tempo 写入 trace再以多种查询方式读回从而校验后端读写一致性。在 cmd/tempo-vulture/main.go 中可以看到它的核心参数-prometheus-listen-address自身指标暴露地址、-tempo-query-url查询端点、-tempo-push-url写入端点。上述 docker-compose 示例中即用-tempo-push-urlhttp://tempo:4317、-tempo-query-urlhttp://tempo:3200挂载了 vulture持续验证示例集群的健康状态。tempo-cli运维与调试工具箱tempo-cli 汇集了所有 Tempo 相关的实用运维功能其子命令覆盖日常排障场景例如cmd-query-search.go、cmd-query-trace-id.go、cmd-query-metrics-query-range.go命令行查询 trace、搜索与指标cmd-analyse-block.go、cmd-analyse-blocks.go分析单个/批量 blockcmd-list-blocks.go、cmd-list-compactionsummary.go列出 block 与压缩概况cmd-migrate-config.go、cmd-migrate-overrides-config.go配置迁移cmd-redact.go、cmd-rewrite-blocks.goblock 脱敏与重写。官方运维文档docs 下的 operations 相关页面提供了这些子命令的完整用法说明。对于生产环境排障、block 巡检与格式迁移tempo-cli 是不可或缺的工具。小结通过本文可以掌握 Grafana Tempo 的核心画像业务定位低成本、高扩展性的分布式追踪后端只需对象存储即可运行与 Grafana/Prometheus/Loki 深度集成README.md查询能力TraceQL 是受 PromQL/LogQL 启发的 traces-first 查询语言支持命令行与 Grafana 双入口其解析与执行引擎完整实现在 pkg/traceql如 engine.go指标联动TraceQL metrics 与 metrics-generator 让 trace 可按任意维度临时聚合为指标并通过 exemplar 实现指标 → trace下钻接入与存储兼容 OpenTelemetry/Jaeger/Zipkin/Kafka 四种协议modules/distributor/receiver后端支持 Azure/GCS/S3/本地磁盘tempodb/backend部署与运维通过 example/docker-compose/single-binary 可一键体验全栈tempo-vulture 与 tempo-cli 分别负责一致性校验与日常排障。如需更深入的内容可继续阅读仓库内的 TraceQL 文档、TraceQL 架构说明 与 TraceQL 查询构造指南或参考 CHANGELOG.md 追踪最新演进当前仓库版本为3.1.0-dev见 VERSION。Tempo 以 AGPL-3.0 协议开源Apache-2.0 例外条款见 LICENSING.md。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Grafana Tempo 完全指南：高吞吐、低成本、与 Grafana 深度集成的分布式追踪后端
Grafana Tempo 完全指南高吞吐、低成本、与 Grafana 深度集成的分布式追踪后端【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempoGrafana Tempo 是一个开源、易用、可支撑大规模数据量的分布式追踪后端以仅需对象存储即可运行的低成本架构著称并与 Grafana、Prometheus、Loki 深度集成。本文以仓库根目录的 README.md 为主线结合仓库源码、部署示例与官方文档系统讲解 Tempo 的核心价值、TraceQL 查询语言与 TraceQL metrics、多协议数据接入与多存储后端架构以及一键部署方案与配套工具链帮助读者快速上手并理解其底层实现。分布式追踪的业务价值为什么需要 Tempo分布式追踪帮助团队快速定位性能问题、理解请求在多个服务之间的流转路径。当服务数量增多、调用链变长时传统日志与指标难以回答一次请求到底经历了什么这一问题而追踪数据恰好补上了这块拼图。Tempo 官方文档强调借助追踪数据可以做比看指标更深入的排查例如对服务故障进行根因分析RCA。README.md 指出Tempo 内置的Traces Drilldown UI前身为 Explore Traces通过无查询式queryless的友好界面让团队无需编写复杂查询即可发现慢请求、错误调用与延迟瓶颈。其关键特性包括直观的 Trace 分析通过简单的点击交互即可发现慢或易错的 traceRED 指标总览基于 Rate、Errors、Duration 三类指标突出性能问题自动化对比自动比较 trace 并识别可疑属性简化可视化无需构造 TraceQL 查询即可获得丰富的可视化数据。追踪数据本身具有树形结构——包含根节点、分支与叶子节点任意位置携带键值key/value元数据与时间戳。这种结构决定了它既能回答某个服务是否变慢也能回答是哪一次具体调用、哪个属性导致了变慢。这正是 TraceQL 这类专为 trace 设计的查询语言发挥价值的场景。TraceQLtraces-first 查询语言设计理念与语法来源Tempo 实现了 TraceQL一门受 LogQL 与 PromQL 启发、以 trace 为第一公民的查询语言。官方文档明确说明TraceQL 在语法与语义上尽可能与 PromQL、LogQL 保持一致docs/sources/tempo/traceql/_index.md因此熟悉 Prometheus 或 Loki 查询的用户可以快速迁移思维PromQL面向指标metrics回答现在系统状态如何LogQL面向日志logs回答发生了什么TraceQL面向 tracespans回答一次请求的完整链路与关键属性是什么。TraceQL 支持精准的定向查询targeted queries也支持由 UI 驱动的富查询分析rich UI-driven analyses。它可以对 trace 的任意属性做筛选——服务名、span 名、持续时间、任意 key/value 标签甚至可以组合多个条件进行复杂的链路过滤。查询入口命令行与 GrafanaTraceQL 的使用入口有两类Grafana 查询编辑器与查询构造器在 Grafana 的 Tempo 数据源Explore中直接书写或可视化构造 TraceQL 查询命令行通过 cmd/tempo-cli 提供的命令直接对后端存储发起查询例如cmd-query-search.go支持从命令行执行 TraceQL 搜索。此外对于不想编写 TraceQL 的用户Traces Drilldown 应用提供了无查询式的分析体验而想要在 Grafana 中编写 TraceQL 的读者可参考 query-editor 文档。前置条件Parquet 列式存储TraceQL 依赖 Apache Parquet 列式存储格式这也是 Tempo 的默认 block 格式。官方文档明确指出TraceQL requires the Parquet columnar format, which is the default block format for Tempodocs/sources/tempo/traceql/_index.md。仓库中 tempodb/encoding/vparquet5、tempodb/encoding/vparquet4、tempodb/encoding/vparquet3 等目录对应不同版本的 Parquet 编码实现也印证了 Tempo 围绕 Parquet 构建查询引擎的架构。引擎实现从源码看 TraceQL 的执行路径在源码层面TraceQL 的解析与执行集中在 pkg/traceql 包中。核心入口是 engine.goCompile(query, opts...)解析并编译 TraceQL 查询返回 AST 根表达式RootExpr、流水线Pipeline、spanset 过滤函数与取数请求FetchSpansRequestCompileFetchSpanRequests支持将一条查询拆分为多个子查询这为数学表达式多子查询类 metrics 查询提供了支撑ExecuteSearch真正执行搜索通过 fetcher 逐层拉取并过滤 spanset。pkg/traceql包还包含完整的语言基础设施lexer.go、parse.go、ast.go、ast_execute.go、ast_metrics.go分别负责词法分析、语法解析、AST 构建、执行与 metrics 语义expr.y/expr.y.go是 goyacc 语法定义enum_operators.go、enum_statics.go、enum_aggregates.go定义了运算符、静态值与聚合函数枚举。整套实现说明 TraceQL 是一门结构完整、可独立编译执行的正规查询语言而非简单的字符串匹配。TraceQL metrics用 trace 生成指标用指标回答哪里慢了README.md 将TraceQL metrics标记为 Grafana Tempo 的实验性experimental特性但它是 Tempo 最具差异化的能力之一。其核心思想是对 trace 查询结果施加一个函数从而从 trace 生成指标。这与 LogQL metric queries 从日志生成指标的方式异曲同工——任何一条已有的 TraceQL 查询都可以按 trace 中任意维度做临时聚合ad hoc aggregation。能力画像对任意 TraceQL 查询结果应用聚合函数如count、min、max、sum、avg、quantile等见 ast_metrics.go 与 engine_metrics.go按 trace 中携带的任意维度服务、span 名、自定义标签等进行聚合无需预先定义指标让指标驱动与trace 驱动两种排查路径打通先看指标发现异常再下钻到具体 trace。与 TraceQL metrics 互补的是 Tempo 的metrics-generator模块modules/generator它能将 trace 聚合成 service graphs 与 span metrics并配合 exemplars实现从 API 延迟指标尖峰跳转到贡献该尖峰的 trace。官方文档在 TraceQL 中专门描述了这条路径metrics-generator 先将 trace 聚合为服务图与 span 指标exemplars 则充当指标与 trace 之间的桥梁。配置示例在单机部署中启用 metrics 处理在 example/docker-compose/single-binary/tempo.yaml 中可以看到完整的 metrics-generator 配置metrics_generator: registry: external_labels: source: tempo cluster: docker-compose storage: path: /var/tempo/generator/wal remote_write: - url: http://prometheus:9090/api/v1/write send_exemplars: true配套的overrides段启用处理器并开启原生直方图overrides: defaults: metrics_generator: processors: [span-metrics, service-graphs] generate_native_histograms: both其中processors字段取值在源码中有明确枚举modules/generator/processor/processor_names.go常用的是span-metricsspan 指标与service-graphs服务调用图generate_native_histograms可设为both同时生成原生与经典直方图。remote_write指向 Prometheus 的/api/v1/write端点并开启send_exemplars从而让 Prometheus 侧能借助 exemplar 跳转到具体 trace。兼容性与存储架构只需对象存储的廉价后端协议兼容Jaeger、Zipkin、Kafka、OpenTelemetryREADME.md 明确声明 Tempo 兼容 Jaeger、Zipkin、Kafka 与 OpenTelemetry 四种数据接入方式它可以按上述任一格式摄取批次ingest batches缓冲后再写入 Azure、GCS、S3 或本地磁盘。这使得 Tempo 作为后端即插即用已有 OpenTelemetry 或 Jaeger 埋点的应用无需改造成本即可接入。在源码层面接收器receiver实现在 modules/distributor/receiver 中直接复用了 OpenTelemetry Collector 生态的接收器组件shim.gootlpreceiverOTLP gRPC / HTTPjaegerreceiverJaeger 协议zipkinreceiverZipkin 协议kafkareceiverKafka 消息中的 trace 数据。shim.go中还通过 usagestats 分别统计receiver_enabled_otlp、receiver_enabled_jaeger、receiver_enabled_zipkin、receiver_enabled_kafka侧面印证了这四类接入方式的正式支持。存储后端Azure、GCS、S3、本地磁盘Tempo 的块存储block storage抽象位于 tempodb/backend为以下后端提供统一接口azureAzure Blob StoragegcsGoogle Cloud Storages3AWS S3 及兼容对象存储local本地磁盘。由于只依赖对象存储Tempo 无需自建数据库或专用存储集群这构成了它robust、cheap、easy to operate健壮、廉价、易运维的架构基础。写入链路为接收器 → 缓冲 → 对象存储读取链路则由 querier/query-frontend 按 block 元数据定位并查询 Parquet 列数据。单机模式的存储配置在 example/docker-compose/single-binary/tempo.yaml 中本地磁盘后端的配置非常简洁storage: trace: backend: local wal: path: /var/tempo/wal # where to store the wal locally local: path: /var/tempo/blockswal目录存放预写日志local.path存放最终落盘的 Parquet block。生产环境将backend切换为s3/gcs/azure并补充对应凭据配置即可。快速开始Docker Compose 一键部署全栈单机示例拓扑仓库提供了多套部署示例example/docker-composeDocker Compose、example/helmHelm、example/tkJsonnet。其中 example/docker-compose/single-binary 演示了最轻量的全栈体验docker-compose.yaml中包含以下服务tempo以-targetall单二进制运行全部模块-config.file/etc/tempo.yaml启动暴露3200Tempo API/查询端口、4317OTLP gRPC、4318OTLP HTTPk6-tracing持续产生模拟 trace 的压测客户端向 alloy 的4317端口推送 OTLP 数据alloyGrafana Alloy 数据采集器作为 OTLP 数据入口再转发至 Tempoprometheus启用 remote-write-receiver、exemplar-storage 与 native-histograms接收 metrics-generator 的 remote writegrafana预置 Tempo/Prometheus 数据源与 dashboard并开启traceqlEditor、metricsSummary功能开关便于直接体验 TraceQLvultureTempo 的一致性校验工具详见下文。关键启动参数与数据流Tempo 容器以-targetall运行全部模块distributor、ingester、querier、query-frontend、metrics-generator 等合一对应的tempo.yaml开启stream_over_http_enabled: true允许 HTTP 流式读取搜索结果与query_frontend.mcp_server.enabled: true。数据流向为k6-tracing (OTLP) → alloy (4317) → tempo distributor (4317/4318 OTLP) ↓ 缓冲与写块 local 磁盘/var/tempo/blocks ↓ metrics-generator Prometheus remote write9090启动该示例只需在目录下执行docker compose up -d随后访问http://localhost:3000Grafana体验 TraceQL 查询与 Traces Drilldown访问http://localhost:3200Tempo 查询 API。配套工具tempo-vulture 与 tempo-cliREADME.md 还介绍了两个与 Tempo 生态强相关的官方工具tempo-vulture一致性校验工具tempo-vulture秃鹫延续 Tempo 的鸟类命名传统用于持续向 Tempo 写入 trace再以多种查询方式读回从而校验后端读写一致性。在 cmd/tempo-vulture/main.go 中可以看到它的核心参数-prometheus-listen-address自身指标暴露地址、-tempo-query-url查询端点、-tempo-push-url写入端点。上述 docker-compose 示例中即用-tempo-push-urlhttp://tempo:4317、-tempo-query-urlhttp://tempo:3200挂载了 vulture持续验证示例集群的健康状态。tempo-cli运维与调试工具箱tempo-cli 汇集了所有 Tempo 相关的实用运维功能其子命令覆盖日常排障场景例如cmd-query-search.go、cmd-query-trace-id.go、cmd-query-metrics-query-range.go命令行查询 trace、搜索与指标cmd-analyse-block.go、cmd-analyse-blocks.go分析单个/批量 blockcmd-list-blocks.go、cmd-list-compactionsummary.go列出 block 与压缩概况cmd-migrate-config.go、cmd-migrate-overrides-config.go配置迁移cmd-redact.go、cmd-rewrite-blocks.goblock 脱敏与重写。官方运维文档docs 下的 operations 相关页面提供了这些子命令的完整用法说明。对于生产环境排障、block 巡检与格式迁移tempo-cli 是不可或缺的工具。小结通过本文可以掌握 Grafana Tempo 的核心画像业务定位低成本、高扩展性的分布式追踪后端只需对象存储即可运行与 Grafana/Prometheus/Loki 深度集成README.md查询能力TraceQL 是受 PromQL/LogQL 启发的 traces-first 查询语言支持命令行与 Grafana 双入口其解析与执行引擎完整实现在 pkg/traceql如 engine.go指标联动TraceQL metrics 与 metrics-generator 让 trace 可按任意维度临时聚合为指标并通过 exemplar 实现指标 → trace下钻接入与存储兼容 OpenTelemetry/Jaeger/Zipkin/Kafka 四种协议modules/distributor/receiver后端支持 Azure/GCS/S3/本地磁盘tempodb/backend部署与运维通过 example/docker-compose/single-binary 可一键体验全栈tempo-vulture 与 tempo-cli 分别负责一致性校验与日常排障。如需更深入的内容可继续阅读仓库内的 TraceQL 文档、TraceQL 架构说明 与 TraceQL 查询构造指南或参考 CHANGELOG.md 追踪最新演进当前仓库版本为3.1.0-dev见 VERSION。Tempo 以 AGPL-3.0 协议开源Apache-2.0 例外条款见 LICENSING.md。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考