Tempo 3.1 aggiunge Kafka ingest più sicuro e trace redaction
Tempo 3.1, la release di distributed tracing descritta da Grafana Labs il 2026-09-30, porta diverse modifiche che contano oltre un singolo prodotto: ingestion più sicura, metriche basate sui trace più accurate, gestione più rigorosa dei dati sensibili e letture più veloci dai trace archiviati. Distributed tracing significa seguire una richiesta mentre passa attraverso servizi diversi, così i team possono vedere dove viene speso il tempo e dove compaiono i guasti.
Un importante cambiamento operativo riguarda la ingestion basata su Kafka. Kafka è un sistema di messaggi usato per spostare dati tra componenti software, e Tempo 3.0 ha spostato la ingestion in modalità microservices su Kafka. In quella release precedente, il client poteva autenticarsi solo con SASL PLAIN, un metodo basato su nome utente e password, e solo tramite una connessione non cifrata. Tempo 3.1 aggiunge TLS, che cifra i dati in transito, e supporta SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER e AWS_MSK_IAM. Per i team che inviano trace attraverso reti o verso sistemi gestiti compatibili con Kafka, le opzioni più ampie di autenticazione e cifratura riducono la necessità di indebolire le impostazioni dei broker solo per accettare traffico trace.
La release aggiunge anche rack-aware fetching tramite una nuova opzione client_rack. Rack-aware fetching, basato su KIP-392, consente ai consumer di leggere da una replica nella propria availability zone quando i broker hanno rack ID configurati. Il problema pratico è costo e latenza: in precedenza Tempo effettuava il fetch dal partition leader ovunque si trovasse, quindi la lettura dei trace poteva attraversare i confini di zone quando il leader era altrove. Grafana Labs nota che questa è un'impostazione lato lettura per block-builders, live-stores e metrics-generators, non per il distributor che scrive record su Kafka. Tempo 3.1 rende inoltre configurabile la compressione del producer. Il distributor ora può usare none, gzip, snappy, lz4 o zstd. Se non viene impostata alcuna opzione, il client Kafka usa snappy per impostazione predefinita. Grafana Labs afferma che questo è importante per backend compatibili con Kafka che accettano un solo codec, citando Azure Event Hubs, che supporta il protocollo Kafka ma accetta solo gzip.
Il cambiamento più rilevante per la sicurezza è la query-based trace redaction. Redaction significa rimuovere in modo permanente i dati dai trace archiviati. Tempo 3.0 aveva aggiunto redaction, ma tempo-cli redact accettava solo trace ID, quindi gli operatori dovevano elencare ogni trace interessato. Tempo 3.1 consente invece agli operatori di inviare una query TraceQL. TraceQL è il linguaggio di query di Tempo per i dati trace. Grafana Labs fornisce un esempio di corrispondenza con un attributo span contenente informazioni personali trapelate e consiglia di iniziare con --dry-run, che conta ciò che verrebbe rimosso senza modificare i block. Il comando stampa un batch ID e il conteggio dei job, mentre metriche per tenant sui conteggi dei job e sui trace corrispondenti o rimossi compaiono nella riga Redaction della dashboard Backend Work inclusa con il monitoring mixin di Tempo.
Questa potenza aggiuntiva comporta rischi. Grafana Labs dichiara che l'esecuzione senza --dry-run riscrive i block e non può essere annullata. Per ridurre le eliminazioni accidentali, la sintassi di query accettata è per ora deliberatamente limitata a un singolo spanset filter con confronti di uguaglianza sugli attributi resource.* e span.*, combinati con && e ||. Gli operatori possono anche usare --start e --end per limitare l'intervallo di tempo, usando now, un offset come now-7d o un timestamp RFC3339. Questo può rendere i job più rapidi ed efficienti nelle installazioni ad alto volume perché Tempo mette in pausa la compaction per un tenant mentre la redaction viene applicata. Grafana Labs avverte che queste opzioni di intervallo temporale dovrebbero essere usate solo dopo che ogni scheduler e worker in una cell esegue almeno Tempo 3.1, perché un worker più vecchio ignora la finestra e rimuove ogni corrispondenza della query in ciascun block che riceve, senza errore e senza percorso di recupero.
Tempo 3.1 modifica anche TraceQL metrics, cioè metriche ad hoc interrogate direttamente dai dati trace. Le query di metriche consapevoli del sampling aggiungono un hint sperimentale with(extrapolate=true). Sampling significa archiviare solo una parte del flusso di trace, per esempio il 50 percento dei trace. Senza correzione, una query rate() su dati con sampling al 50 percento riporta circa metà del traffico sottostante. Il nuovo hint legge il sampling rate dal campo OpenTelemetry probability sampling in tracestate, quando presente, e scala gli span di conseguenza. Con sampling al 50 percento, ogni span archiviato conta come due, quindi una query che trova 1.000 span riporta 2.000. Gli span senza un sampling rate registrato contano come uno, il che rende sicura l'adozione parziale. Grafana Labs afferma che l'hint richiede block vParquet4 o successivi e si applica a rate, count_over_time, sum_over_time, avg_over_time, histogram_over_time, quantile_over_time e compare, ma non a min_over_time o max_over_time.
TraceQL metrics ora può usare gli operatori aritmetici +, -, * e / tra due query di metriche, quindi un calcolo del tasso di errore può dividere una query sul tasso di errore per una query sul traffico totale dentro TraceQL stesso. Ogni sotto-query richiede parentesi, e gli scalari possono essere usati su entrambi i lati, per esempio moltiplicando un quantile di durata per 1000 per esprimerlo in millisecondi. Quando le query sono raggruppate, le series si combinano solo quando i loro label set corrispondono esattamente; un lato senza label viene trasmesso a ogni series sull'altro lato. L'hint extrapolate può essere applicato all'intera espressione aritmetica, ma Grafana Labs afferma che collocare with(...) dentro una sotto-query è un errore di sintassi.
Le query di metriche dovrebbero anche diventare più veloci man mano che vengono scritti nuovi dati. Il percorso di fetch span-only introdotto sperimentalmente in Tempo 3.0 è ora abilitato per impostazione predefinita per i block vParquet5, il formato block predefinito in Tempo 3.1. Apache Parquet è un formato di archiviazione basato su colonne progettato per letture analitiche efficienti. Le query che non richiedono l'intera struttura del trace possono elaborare singoli span invece di trace completi, riducendo latenza e uso della memoria. Grafana Labs riferisce che, in un test a caldo, una semplice query { } | rate() con span-only fetch abilitato è stata completata in poco più della metà del tempo della stessa query con tale funzione disabilitata. Gli operatori possono disattivarla per tenant o per query.
Il metrics-generator, un componente opzionale di Tempo che trasforma gli span ingeriti in metriche RED (rate, errors e duration) e service graphs, riceve anch'esso diversi aggiornamenti. Un nuovo label unmatched_span_kind sul contatore degli edge scaduti aiuta a spiegare i link mancanti nelle service-map mostrando quale lato di una coppia di span client-server non è arrivato. Tempo 3.1 riconosce inoltre il cambiamento della semantic convention di OpenTelemetry da db.system a db.system.name, accettando entrambi per identificare le richieste di database e denominare virtual nodes. Se entrambi gli attributi sono presenti, db.system ha la precedenza, evitando rinomine di dashboard e alert dopo aggiornamenti dei software development kit. Grafana Labs afferma inoltre che i processor span-metrics e service-graphs ora prendono in prestito buffer di label in pool invece di allocarne di nuovi ogni volta, con benchmark service-graphs in steady-state che riportano zero allocation per operation.
Per la lettura di singoli trace, Tempo 3.1 aggiunge span pruning sperimentale sull'endpoint trace-by-ID v2.