Tempo 3.1 ergänzt sichereren Kafka ingest und trace redaction
Tempo 3.1, das distributed tracing Release, das Grafana Labs am 2026-09-30 beschrieben hat, bringt mehrere Änderungen, die über ein einzelnes Produkt hinaus wichtig sind: sicherere ingestion, genauere trace-basierte metrics, strengere Handhabung sensibler Daten und schnelleres Lesen aus gespeicherten traces. Distributed tracing bedeutet, eine Anfrage zu verfolgen, während sie verschiedene services durchläuft, damit Teams sehen können, wo Zeit verbraucht wird und wo Fehler auftreten.
Eine wichtige betriebliche Änderung betrifft Kafka-basierte ingestion. Kafka ist ein Nachrichtensystem, das verwendet wird, um Daten zwischen Softwarekomponenten zu bewegen, und Tempo 3.0 verlagerte microservices-mode ingestion auf Kafka. In diesem früheren Release konnte sich der client nur mit SASL PLAIN authentifizieren, einer Methode mit Benutzername und Passwort, und nur über eine unverschlüsselte Verbindung. Tempo 3.1 ergänzt TLS, das Daten während der Übertragung verschlüsselt, und unterstützt SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER und AWS_MSK_IAM. Für Teams, die traces über Netzwerke oder in verwaltete Kafka-kompatible Systeme senden, verringern die breiteren Authentifizierungs- und Verschlüsselungsoptionen die Notwendigkeit, broker-Einstellungen abzuschwächen, nur um trace traffic anzunehmen.
Das Release ergänzt außerdem rack-aware fetching über eine neue client_rack Option. Rack-aware fetching, basierend auf KIP-392, ermöglicht es consumers, von einer replica in ihrer eigenen availability zone zu lesen, wenn broker mit rack IDs konfiguriert sind. Das praktische Thema sind Kosten und Latenz: Tempo rief zuvor Daten vom partition leader ab, egal wo dieser lief, sodass das Lesen von traces zone-Grenzen überschreiten konnte, wenn sich der leader anderswo befand. Grafana Labs weist darauf hin, dass dies eine read-side Einstellung für block-builders, live-stores und metrics-generators ist, nicht für den distributor, der records nach Kafka schreibt. Tempo 3.1 macht außerdem producer compression konfigurierbar. Der distributor kann nun none, gzip, snappy, lz4 oder zstd verwenden. Wenn keine Option gesetzt ist, verwendet der Kafka client standardmäßig snappy. Grafana Labs sagt, dass dies für Kafka-kompatible backends wichtig ist, die nur einen codec akzeptieren, und nennt Azure Event Hubs als Beispiel, das das Kafka protocol unterstützt, aber nur gzip akzeptiert.
Die sicherheitsrelevanteste Änderung ist query-based trace redaction. Redaction bedeutet, Daten dauerhaft aus gespeicherten traces zu entfernen. Tempo 3.0 fügte redaction hinzu, aber tempo-cli redact akzeptierte nur trace IDs, sodass operators jede betroffene trace einzeln auflisten mussten. Tempo 3.1 ermöglicht es operators stattdessen, eine TraceQL query einzureichen. TraceQL ist Tempos query language für trace data. Grafana Labs nennt ein Beispiel für das Abgleichen eines span attribute, das geleakte personenbezogene Informationen enthält, und empfiehlt, mit --dry-run zu beginnen, wodurch gezählt wird, was entfernt würde, ohne blocks zu ändern. Der command gibt eine batch ID und job count aus, während per-tenant metrics für job counts und abgeglichene oder entfernte traces in der Redaction Zeile des Backend Work dashboard erscheinen, das im monitoring mixin von Tempo enthalten ist.
Diese zusätzliche Leistung bringt Risiken mit sich. Grafana Labs erklärt, dass ein Lauf ohne --dry-run blocks neu schreibt und nicht rückgängig gemacht werden kann. Um versehentliche Löschungen zu reduzieren, ist die akzeptierte query syntax vorerst bewusst auf einen einzelnen spanset filter mit equality comparisons gegen resource.* und span.* attributes beschränkt, kombiniert mit && und ||. Operators können außerdem --start und --end verwenden, um den Zeitraum einzuschränken, mit now, einem offset wie now-7d oder einem RFC3339 timestamp. Dies kann jobs in Installationen mit hohem Volumen schneller und effizienter machen, weil Tempo compaction für einen tenant pausiert, während redaction angewendet wird. Grafana Labs warnt, dass diese time range options nur verwendet werden sollten, nachdem jeder scheduler und worker in einer cell mindestens Tempo 3.1 ausführt, weil ein älterer worker das window ignoriert und jeden query match in jedem block entfernt, den er erhält, ohne Fehler und ohne recovery path.
Tempo 3.1 ändert auch TraceQL metrics, also ad hoc metrics, die direkt aus trace data abgefragt werden. Sampling-aware metrics queries ergänzen einen experimentellen with(extrapolate=true) hint. Sampling bedeutet, nur einen Teil des trace stream zu speichern, zum Beispiel 50 Prozent der traces. Ohne Korrektur meldet eine rate() query über zu 50 Prozent gesampelte Daten etwa die Hälfte des zugrunde liegenden traffic. Der neue hint liest die sampling rate aus dem OpenTelemetry probability sampling field in tracestate, sofern vorhanden, und skaliert spans entsprechend. Bei 50 Prozent sampling zählt jeder gespeicherte span als zwei, sodass eine query, die 1.000 spans matched, 2.000 meldet. Spans ohne aufgezeichnete sampling rate zählen als eins, was eine teilweise Einführung sicher macht. Grafana Labs sagt, dass der hint vParquet4 blocks oder neuer erfordert und für rate, count_over_time, sum_over_time, avg_over_time, histogram_over_time, quantile_over_time und compare gilt, aber nicht für min_over_time oder max_over_time.
TraceQL metrics können nun arithmetic operators +, -, * und / zwischen zwei metrics queries verwenden, sodass eine error-rate calculation eine error rate query durch eine total traffic query innerhalb von TraceQL selbst dividieren kann. Jede sub-query benötigt parentheses, und scalars können auf beiden Seiten verwendet werden, zum Beispiel indem ein duration quantile mit 1000 multipliziert wird, um es in Millisekunden auszudrücken. Wenn queries grouped sind, werden series nur kombiniert, wenn ihre label sets exakt übereinstimmen; eine Seite ohne labels wird über jede series auf der anderen Seite broadcast. Der extrapolate hint kann auf den gesamten arithmetic expression angewendet werden, aber Grafana Labs sagt, dass with(...) innerhalb einer sub-query ein syntax error ist.
Metrics queries sollten außerdem schneller werden, wenn neue Daten geschrieben werden. Der span-only fetch path, der in Tempo 3.0 experimentell eingeführt wurde, ist nun standardmäßig für vParquet5 blocks aktiviert, das default block format in Tempo 3.1. Apache Parquet ist ein column-based storage format, das für effiziente analytical reads entwickelt wurde. Queries, die nicht die vollständige trace structure benötigen, können einzelne spans statt ganzer traces verarbeiten, was latency und memory use reduziert. Grafana Labs berichtet, dass in einem warmed-up test eine einfache { } | rate() query mit aktiviertem span-only fetch in etwas mehr als der Hälfte der Zeit derselben query mit deaktivierter Option abgeschlossen wurde. Operators können pro tenant oder pro query opt out verwenden.
Der metrics-generator, eine optionale Tempo component, die ingested spans in RED metrics (rate, errors und duration) und service graphs umwandelt, erhält ebenfalls mehrere Updates. Ein neues unmatched_span_kind label auf dem expired edges counter hilft, fehlende service-map links zu erklären, indem es zeigt, welche Seite eines client-server span pair nicht angekommen ist. Tempo 3.1 erkennt außerdem die Änderung der OpenTelemetry semantic convention von db.system zu db.system.name und akzeptiert beide zur Identifizierung von database requests und Benennung von virtual nodes. Wenn beide attributes vorhanden sind, hat db.system Vorrang, wodurch dashboard- und alert-Umbenennungen nach software development kit upgrades vermieden werden. Grafana Labs sagt außerdem, dass die span-metrics und service-graphs processors nun pooled label buffers ausleihen, statt jedes Mal neue zuzuweisen, wobei steady-state service-graphs benchmarks null allocations per operation melden.
Für das Lesen einzelner traces ergänzt Tempo 3.1 experimentelles span pruning auf dem trace-by-ID v2 endpoint.