Grafana Tempo 3.1: Kafka with TLS, TraceQL-based redaction, vParquet5 by default

Grafana released Tempo 3.1 on 30 September 2026, as announced on the project's official blog. For teams running Tempo clusters in production, the release brings three concrete changes: more secure Kafka ingestion, a data redaction tool that no longer requires enumerating trace IDs, and a new default block format.

Kafka: TLS and lower network costs

Up to 3.0, the Kafka client used by Tempo in microservices mode could only connect using SASL PLAIN authentication, without TLS, which ruled out any broker requiring encrypted connections. 3.1 adds TLS support and four additional SASL mechanisms: SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER and AWS_MSK_IAM, configurable under the ingest.kafka section with parameters such as tls_enabled, tls_ca_path and sasl_mechanism.

There's also client_rack, a community-contributed option that enables rack-aware fetching (KIP-392): consumers can read from a replica in their own availability zone instead of always hitting the partition leader, cutting down on cross-zone transfer costs billed by the cloud provider. This is a read-side setting, so it applies to the block-builder, live-store and metrics-generator, but not to the distributor, which writes to Kafka.

Finally, producer_compression lets you choose the compression codec (gzip, snappy, lz4, zstd or none), which is useful for backends that only accept a single format: Azure Event Hubs, for instance, only supports gzip, and prior to 3.1 this ruled it out as a usable backend.

Trace redaction via queries, not single IDs anymore

Since Tempo 3.0, tempo-cli redact has existed to remove sensitive data from storage, but it only accepted individual trace IDs: if a piece of data (an email address, token, or account number) ended up in many spans, you had to enumerate every single one. With 3.1 you can now redact traces matching a TraceQL query instead of enumerating their IDs, so an incident involving sensitive data no longer requires manually reconstructing every trace involved. The command supports --dry-run to count matches without modifying blocks, before running the actual removal, which is irreversible.

More accurate and faster TraceQL metrics

This version also introduces extrapolation for sampled data: Tempo 3.1 lets TraceQL metrics extrapolate counts from the sampling probability recorded in each span, so rate and count queries reflect real traffic without needing a separate metrics pipeline, via the experimental with(extrapolate=true) hint; this requires vParquet4 blocks or later. Anyone using partial trace sampling can thus obtain accurate traffic estimates without adding extra instrumentation.

vParquet5 by default

As of this release, Tempo 3.1 writes new blocks in vParquet5 format; existing vParquet4 and vParquet3 blocks remain readable and no data migration is required. Those upgrading therefore don't need to rewrite existing storage, but new data will use the latest format.

For full configuration details, Grafana points to the release notes and the official Tempo 3.1 changelog.