Grafana Tempo 3.1 bringt Query-basiertes Trace-Redaction und Sampling-aware TraceQL-Metriken
Das erste Minor-Release der 3.0-Architektur ergänzt TLS und weitere SASL-Mechanismen für den Kafka-Client. Redaction lässt sich jetzt per TraceQL-Query statt per Trace-ID-Liste steuern, dazu kommt ein experimenteller Query-Time-Hint für TraceQL-Metriken.
Das Release baut auf Tempo 3.0 auf, das im Juni erschienen war und die Kafka-kompatible Architektur (Codename Project Rhythm) zum Standard für Microservices-Deployments machte. In diesem Design schreiben Distributoren in ein Kafka-Topic. Block-Builder konsumieren das Topic, um Parquet-Blöcke in Object Storage zu schreiben, und Live-Stores konsumieren es, um aktuelle Traces bereitzustellen. Ingesters und Compactors entfallen, ersetzt durch einen Backend-Scheduler und Worker. Grafana erklärt, dass der Verzicht auf Replikationsfaktor 3 die Speichergröße von dem Drei- bis Dreieinhalbfachen des Trace-Volumens auf eine einzige Kopie reduziert. Der Monolithic-Modus bleibt weiterhin ohne Kafka.
Da Kafka sich nun auf dem kritischen Pfad befindet, wurden die Grenzen des 3.0-Clients zu einem Problem. Er unterstützte lediglich SASL PLAIN über eine unverschlüsselte Verbindung, sodass jeder Broker, der TLS verlangte, ihn ablehnte. Tempo 3.1 ergänzt TLS, einschließlich optionalen mTLS, sowie SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER und AWS_MSK_IAM.
Eine neue Option client_rack ermöglicht rack-bewusstes Abrufen (KIP-392), sodass Block-Builder, Live-Stores und Metrics-Generatoren aus einem Replikat in ihrer eigenen Availability Zone lesen können und so gebührenpflichtige zonenuenübergreifende Transfers vermeiden. Dafür sind Broker mit konfigurierten Rack-IDs erforderlich. Eine neue Option producer_compression akzeptiert none, gzip, snappy, lz4 oder zstd; ohne Angabe ist der Standardwert snappy.
Grafana weist darauf hin, dass dies zusammen mit TLS Azure Event Hubs als Backend nutzbar macht, da der Dienst ausschließlich gzip akzeptiert. Alle drei Änderungen stammen von Community-Beitragenden.
Das Trace-Redaction, das in 3.0 über tempo-cli redact eingeführt worden war, erforderte bisher das Aufzählen von Trace-IDs. Sensible Werte wie Tokens oder Kontonummern treten jedoch häufig in mehr Traces auf, als sich praktisch auflisten lassen. In 3.1 nimmt der Befehl eine TraceQL-Abfrage entgegen und unterstützt --dry-run, das Treffer zählt, ohne Blöcke zu verändern.
Grafana beschränkt die Syntax auf einen einzigen Spanset-Filter. Dabei werden Gleichheitsvergleiche auf resource.*- und span.*-Attributen sowie && und || verwendet. Das liegt daran, dass die Umschreibung nicht rückgängig gemacht werden kann. Die Flags --start und --end grenzen den Zeitraum ein, was wichtig ist, weil Tempo die Kompaktierung für einen Tenant anhält, während eine Redaction ausgeführt wird.
Grafana warnt, dass ältere Worker das Zeitfenster ignorieren und jeden Treffer in jedem empfangenen Block entfernen, ohne einen Fehler auszulösen. Die Flags sollten erst eingesetzt werden, wenn jeder Scheduler und Worker auf 3.1 läuft.
TraceQL Metrics, das in 3.0 allgemein verfügbar wurde, erhält drei Änderungen. Der experimentelle Hinweis with (extrapolate=true) skaliert anhand der Sampling-Rate in tracestate. Damit folgt das Feature den Wahrscheinlichkeits-Sampling-Regeln von OpenTelemetry.
Bei 50 Prozent Sampling zählt jeder gespeicherte Span doppelt. Spans ohne aufgezeichnete Rate zählen einfach, sodass eine teilweise Einführung die Werte anderer Dienste nicht verfälscht. Die Funktion greift bei rate, count_over_time, sum_over_time, avg_over_time, histogram_over_time, quantile_over_time und compare, nicht jedoch bei min_over_time oder max_over_time.
Voraussetzung ist vParquet4 oder neuer, und die Rate wird auf dieselbe Weise gelesen wie beim Setting enable_tracestate_span_multiplier des Metrics-Generators aus 3.0, sodass Ad-hoc-Abfragen und voraggregierte Serien übereinstimmen sollten. Zweitens funktionieren +, -, * und / nun zwischen Metrics-Abfragen und Skalaren, wodurch sich eine Error Rate als einzelne Abfrage ausdrücken lässt. Drittens ist der rein span-basierte Abrufpfad, der in 3.0 experimentell war, für vParquet5-Blöcke nun standardmäßig aktiviert.
In einem aufgewärmten Test lieferte { } | rate() das Ergebnis in etwas mehr als der halben Zeit.
Zu den weiteren Neuerungen gehört eine experimentelle Option zum Beschneiden von Spans am v2-Trace-by-ID-Endpunkt, der ähnliche Leaf-Spans zu einem zusammenfassenden Span mit Count- und Duration-Statistiken zusammenfasst. Derselbe Endpunkt erhält zudem TraceQL-Filterung. Ein neuer experimenteller Endpunkt POST /api/v2/traces/diff vergleicht zwei Traces und kann statt eines Spans-Level-Patch eine kompakte Zusammenfassung zurückgeben.
Er ist über gcx, tempo-cli und den Tempo MCP Server zugänglich, wo laut Grafana die kleinere Payload LLM-gestützte Untersuchungen erleichtert. Der Metrics-Generator erhält ein Label unmatched_span_kind für abgelaufene Service-Graph-Kanten, Unterstützung für das in OpenTelemetry umbenannte Attribut db.system.name sowie gepoolte Label-Buffer, durch die laut Grafana die Allokationen pro Span in seinen Service-Graph-Benchmarks auf null sinken.
Präsentiert von: Martin Reynolds, Field CTO bei Harness, und Barani Mohandoss, Director, Cloud Governance, FinOps & E-Tools bei Trimble
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
The release builds on Tempo 3.0, published in June, which made the Kafka-compatible architecture (codenamed Project Rhythm) the default for microservices deployments. In that design, distributors write to a Kafka topic. Block-builders consume the topic to write Parquet blocks to object storage, and live-stores consume it to serve recent traces. Ingesters and compactors are gone, replaced by a backend scheduler and workers. Grafana says dropping replication factor 3 reduces storage from 3 to 3.5 times the trace volume to a single copy. Monolithic mode remains Kafka-free.
Because Kafka is now on the critical path, the 3.0 client's limits became a problem. It supported only SASL PLAIN over an unencrypted connection, so any broker requiring TLS refused it. Tempo 3.1 adds TLS, including optional mTLS, plus SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER, and AWS_MSK_IAM.
A new client_rack option enables rack-aware fetching (KIP-392), so block-builders, live-stores, and metrics-generators can read from a replica in their own availability zone and avoid cross-zone transfer charges. It requires brokers with rack IDs configured. A new producer_compression option accepts none, gzip, snappy, lz4, or zstd; unset, it defaults to snappy.
Grafana notes that this, together with TLS, makes Azure Event Hubs usable as a backend, since it accepts only gzip. All three changes came from community contributors.
Trace redaction, introduced in 3.0 through t`empo-cli redact`, previously required enumerating trace IDs. Sensitive values such as tokens or account numbers often appear across more traces than can practically be listed. In 3.1 the command takes a TraceQL query and supports --dry-run, which counts matches without modifying blocks.
Grafana limits the syntax to one spanset filter. It uses equality comparisons on resource.* and span.* attributes, along with && and ||. This is because the rewrite cannot be undone. --start and --end flags narrow the time range, which matters because Tempo pauses compaction for a tenant while a redaction applies.
Grafana warns that older workers ignore the window and remove every match in each block they receive, without an error. The flags should only be used once every scheduler and worker runs 3.1.
TraceQL metrics, which became generally available in 3.0, gains three changes. The experimental hint with (extrapolate=true) scales by the sampling rate in tracestate. This follows OpenTelemetry's probability sampling rules.
At 50% sampling, each stored span counts as two. Spans without a recorded rate count as one, so partial adoption does not distort other services. It applies to: rate, count_over_time, sum_over_time, avg_over_time, histogram_over_time, quantile_over_time, and compare, but not to min_over_time or max_over_time.
It requires vParquet4 or later and reads the rate the same way as the metrics-generator's enable_tracestate_span_multiplier setting from 3.0, so ad-hoc queries and pre-aggregated series should agree. Second, +, -, *, and / now work between metrics queries and scalars, so an error rate becomes a single query. Third, the span-only fetch path, experimental in 3.0, is now on by default for vParquet5 blocks.
In one warmed-up test, { } | rate() finished in slightly over half the time.
Other additions include 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. The same endpoint gains TraceQL filtering. A new experimental POST /api/v2/traces/diff endpoint compares two traces and can return a compact summary instead of a span-level patch. It is exposed through gcx, tempo-cli, and the Tempo MCP server, where Grafana says the smaller payload helps LLM-driven investigations. The metrics-generator gets an unmatched_span_kind label on expired service-graph edges, support for the renamed OpenTelemetry db.system.name attribute, and pooled label buffers that Grafana reports reduce per-span allocations to zero in its service-graph benchmarks.
Presented by: Martin Reynolds - Field CTO at Harness, and Barani Mohandoss - Director, Cloud Governance, FinOps & E-Tools at Trimble