查询速度翻倍，Tempo 3.1把脱敏从列ID改成写查询

Grafana Labs 发布了 Tempo 3.1，这是 3.0 架构之后的第一个小版本更新。官方给出的一个数字很直接：简单的指标查询现在跑起来接近快了一倍。

这次更新里最值得拿出来说的，是追踪数据的脱敏方式变了。以前要脱敏，得先把 trace ID 一个个列出来；现在可以直接写一条 TraceQL 查询。

为什么列 ID 这条路走不通

Tempo 3.0 引入了通过 tempo-cli redact 做追踪脱敏的能力，但当时要求把 trace ID 枚举出来。问题在于，像 token 或账号这类敏感值，出现的追踪数量往往多到根本列不完。

3.1 里这个命令改成接收一条 TraceQL 查询，并且支持 --dry-run，只统计匹配数量、不改动数据块。Grafana 把语法限制为单个 spanset 过滤器，用 resource.* 和 span.* 属性上的等值比较，配合 && 和 ||。这么限制的原因是重写操作无法撤销。

--start 和 --end 两个参数用来收窄时间范围，这一点很关键：脱敏执行期间，Tempo 会暂停该租户的 compaction。Grafana 同时提醒，旧版本的 worker 会忽略这个时间窗口，把它们收到的每个数据块里的所有匹配项都删掉，而且不会报错。所以这两个参数只有在所有 scheduler 和 worker 都跑上 3.1 之后才能用。

Kafka 上了关键路径，客户端短板就藏不住了

3.1 建立在 6 月发布的 Tempo 3.0 之上。3.0 把兼容 Kafka 的架构（代号 Project Rhythm）变成了微服务部署的默认选项。在这个设计里，distributor 写入一个 Kafka topic，block-builder 消费该 topic 把 Parquet 数据块写进对象存储，live-store 消费它来提供近期追踪数据。ingester 和 compactor 被移除，由后端 scheduler 和 worker 取代。Grafana 表示，去掉复制因子 3 之后，存储占用从追踪数据量的 3 到 3.5 倍降到单份副本。单体模式仍然不依赖 Kafka。

Kafka 既然进了关键路径，3.0 客户端的限制就成了麻烦。它只支持在未加密连接上使用 SASL PLAIN，任何要求 TLS 的 broker 都会直接拒绝。3.1 补上了 TLS（包括可选的 mTLS），以及 SCRAM-SHA-256、SCRAM-SHA-512、OAUTHBEARER 和 AWS_MSK_IAM。

新增的 client_rack 选项启用了机架感知拉取（KIP-392），block-builder、live-store 和 metrics-generator 可以从自己所在可用区的副本读取，避开跨区传输费用，前提是 broker 配置了机架 ID。新增的 producer_compression 选项接受 none、gzip、snappy、lz4 或 zstd，不设置时默认 snappy。Grafana 指出，这一项加上 TLS，让 Azure Event Hubs 可以作为后端使用，因为它只接受 gzip。这三处改动都来自社区贡献者。

采样数据的指标修正，靠一个实验性提示

TraceQL 指标在 3.0 中正式可用，这次拿到三处变化。实验性提示 with (extrapolate=true) 会按照 tracestate 中的采样率做缩放，遵循 OpenTelemetry 的概率采样规则。50% 采样时，每个存储的 span 按两个计算；没有记录采样率的 span 按一个计算，所以部分服务采用不会扭曲其他服务的数据。

它适用于 rate、count_over_time、sum_over_time、avg_over_time、histogram_over_time、quantile_over_time 和 compare，但不适用于 min_over_time 和 max_over_time。该功能要求 vParquet4 或更高版本，读取采样率的方式与 3.0 中 metrics-generator 的 enable_tracestate_span_multiplier 设置一致，因此临时查询和预聚合序列的结果应当吻合。

第二处变化是 +、-、*、/ 现在可以用于指标查询和标量之间，错误率因此变成一条查询就能算出来。第三处是仅 span 的拉取路径，3.0 中还是实验性的，现在对 vParquet5 数据块默认开启。在一次预热过的测试中，{ } | rate() 的完成时间略多于原来的一半。

vParquet5 成为默认，还有几个实验性接口

vParquet5 成为默认的数据块格式。其他新增内容包括 trace-by-ID v2 接口上的一个实验性 span 剪枝选项，它把相似的叶子 span 合并成一个摘要 span，携带数量和耗时统计。同一个接口还获得了 TraceQL 过滤能力。

新增的实验性 POST /api/v2/traces/diff 接口用来比较两条追踪，可以返回紧凑摘要而不是 span 级别的补丁。它通过 gcx、tempo-cli 和 Tempo MCP server 暴露，Grafana 表示更小的载荷有助于 LLM 驱动的排查。

metrics-generator 方面，过期的服务图边上多了 unmatched_span_kind 标签，支持改名后的 OpenTelemetry db.system.name 属性，并引入了池化的标签缓冲区——Grafana 称在其服务图基准测试中，这把每个 span 的分配次数降到了零。