Grafana Labs has released Tempo 3.1, the first minor update to the 3.0 architecture, delivering query performance that runs nearly twice as fast for simple metrics queries. The update, announced in October 2026, builds on the Kafka-compatible architecture introduced in June and adds critical security features, trace redaction capabilities, and experimental query-time corrections for sampled data. The release makes vParquet5 the default block format and addresses major limitations in the Kafka client that prevented use with encrypted brokers.
The update introduces TLS support and multiple SASL mechanisms to the Kafka client, including optional mTLS, SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER, and AWS_MSK_IAM. A new client_rack option enables rack-aware fetching through KIP-392, allowing block-builders, live-stores, and metrics-generators to read from replicas in their own availability zone and avoid cross-zone transfer charges when brokers have rack IDs configured. A producer_compression option now accepts none, gzip, snappy, lz4, or zstd, defaulting to snappy when unset. Together with TLS, these changes make Azure Event Hubs usable as a backend since it accepts only gzip compression. All three features came from community contributors.
Trace redaction, which launched in 3.0 through tempo-cli redact with a list of trace IDs, now accepts a TraceQL query and supports a dry-run mode that counts matches without modifying blocks. According to Grafana, the syntax is limited to one spanset filter using equality comparisons on resource and span attributes, combined with logical AND and OR operators, because the rewrite can't be undone. The company warns that older workers ignore the time window flags and remove every match in each block they receive without throwing an error, so the flags should only be used once every scheduler and worker runs 3.1. TraceQL metrics gains an experimental hint that scales by the sampling rate in tracestate, following OpenTelemetry's probability sampling rules—at 50% sampling, each stored span counts as two.
Grafana explains that the 3.0 architecture dropped the replication factor of 3, reducing storage from 3 to 3.5 times the trace volume down to a single copy, with distributors writing to a Kafka topic that block-builders consume to write Parquet blocks to object storage while live-stores consume it to serve recent traces. Because Kafka now sits on the critical path, the original client's limitation to SASL PLAIN over unencrypted connections became a problem, as any broker requiring TLS refused it. The span-only fetch path, experimental in 3.0, is now enabled by default for vParquet5 blocks, and in one warmed-up test a basic rate query finished in slightly over half the time. The metrics-generator now uses pooled label buffers that reduce per-span allocations to zero in Grafana's service-graph benchmarks.
The release also introduces an experimental span pruning option on the trace-by-ID v2 endpoint, which collapses similar leaf spans into one summary span carrying count and duration statistics, plus a new experimental POST endpoint that compares two traces and can return a compact summary instead of a span-level patch. Grafana notes the smaller payload helps LLM-driven investigations when exposed through gcx, tempo-cli, and the Tempo MCP server. The doubling of query performance and community-driven security enhancements position Tempo for broader enterprise adoption, particularly in multi-cloud environments where zone transfer costs and broker encryption were previously blocking factors. For teams already running sampled tracing at scale, the extrapolation hint promises more accurate metrics without requiring full instrumentation across every service—though the careful rollout warnings around redaction suggest operators will need to coordinate upgrades tightly to avoid data loss.