Grafana Tempo 3.1: Kafka con TLS, redazione via TraceQL, vParquet5 di default

Grafana ha rilasciato Tempo 3.1 il 30 settembre 2026, come riportato nel blog ufficiale del progetto. Per chi opera cluster Tempo in produzione, la release porta tre cambi concreti: ingestion Kafka più sicura, uno strumento di redazione dati che non richiede più di enumerare i trace ID, e un nuovo formato di blocco di default.

Kafka: TLS e meno costi di rete

Fino alla 3.0, il client Kafka usato da Tempo in modalità microservizi si collegava solo con autenticazione SASL PLAIN e senza TLS, il che escludeva qualsiasi broker che richiedesse connessioni cifrate. La 3.1 aggiunge supporto TLS e quattro meccanismi SASL in più: SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER e AWS_MSK_IAM, da configurare nella sezione ingest.kafka con parametri come tls_enabled, tls_ca_path e sasl_mechanism.

Arriva anche client_rack, un'opzione contributo della community che abilita il fetch rack-aware (KIP-392): i consumer possono leggere da una replica nella propria zona di disponibilità invece che sempre dal leader della partizione, riducendo i costi di trasferimento cross-zone fatturati dal cloud provider. È un'impostazione lato lettura, quindi si applica a block-builder, live-store e metrics-generator, non al distributor che scrive su Kafka.

Infine producer_compression permette di scegliere il codec di compressione (gzip, snappy, lz4, zstd o none), utile per backend che accettano un solo formato: Azure Event Hubs, ad esempio, supporta solo gzip, e prima della 3.1 questo lo escludeva come backend utilizzabile.

Redazione tracce via query, non più per singolo ID

Da Tempo 3.0 esisteva tempo-cli redact per rimuovere dati sensibili dallo storage, ma accettava solo trace ID singoli: se un dato (email, token, numero di conto) finiva in molti span, bisognava enumerarli tutti. Con la 3.1 è possibile redigere le tracce che corrispondono a una query TraceQL invece di enumerarne gli ID, così un incidente con dati sensibili non richiede più di ricostruire a mano ogni traccia coinvolta. Il comando supporta --dry-run per contare le corrispondenze senza modificare i blocchi, prima di eseguire la rimozione effettiva, che è irreversibile.

Metriche TraceQL più accurate e veloci

La versione introduce anche l'estrapolazione per dati campionati: Tempo 3.1 lets TraceQL metrics extrapolate counts from the sampling probability recorded in each span, così le query su rate e conteggi riflettono il traffico reale senza una pipeline di metriche separata, tramite l'hint sperimentale with(extrapolate=true); richiede blocchi vParquet4 o successivi. Chi usa sampling parziale delle tracce può così ottenere stime corrette del traffico senza aggiungere strumentazione extra.

vParquet5 di default

Da questa release, Tempo 3.1 scrive i nuovi blocchi in formato vParquet5; i blocchi esistenti in vParquet4 e vParquet3 restano leggibili e non serve alcuna migrazione dati. Chi aggiorna non deve quindi riscrivere lo storage esistente, ma i nuovi dati useranno il formato più recente.

Per i dettagli di configurazione completi, Grafana rimanda alle note di rilascio e al changelog ufficiale di Tempo 3.1.