Tempo 3.1 shton Kafka ingest më të sigurt dhe trace redaction
Tempo 3.1, release i distributed tracing i përshkruar nga Grafana Labs më 2026-09-30, sjell disa ndryshime që kanë rëndësi përtej një produkti: ingestion më të sigurt, metrics më të sakta të bazuara në trace, trajtim më të rreptë të të dhënave të ndjeshme dhe lexime më të shpejta nga traces të ruajtura. Distributed tracing do të thotë të ndjekësh një request ndërsa kalon nëpër services të ndryshme, që ekipet të shohin ku shpenzohet koha dhe ku shfaqen dështimet.
Një ndryshim i madh operacional është te ingestion i bazuar në Kafka. Kafka është një message system që përdoret për të lëvizur të dhëna ndërmjet software components, dhe Tempo 3.0 e kaloi ingestion në microservices-mode mbi Kafka. Në atë release të mëparshëm, client mund të bënte authenticate vetëm me SASL PLAIN, një metodë me username-and-password, dhe vetëm mbi një connection të paenkriptuar. Tempo 3.1 shton TLS, që enkripton të dhënat in transit, dhe mbështet SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER dhe AWS_MSK_IAM. Për ekipet që dërgojnë traces nëpër networks ose drejt sistemeve të menaxhuara të përputhshme me Kafka, opsionet më të gjera të authentication dhe encryption ulin nevojën për të dobësuar broker settings vetëm që të pranohet trace traffic.
Release gjithashtu shton rack-aware fetching përmes një opsioni të ri client_rack. Rack-aware fetching, bazuar në KIP-392, u lejon consumers të lexojnë nga një replica në availability zone të tyre kur brokers kanë rack IDs të konfiguruara. Çështja praktike është kostoja dhe latency: Tempo më parë merrte të dhëna nga partition leader kudo që ndodhej, ndaj leximi i traces mund të kalonte kufijtë e zone kur leader ishte diku tjetër. Grafana Labs vëren se ky është një read-side setting për block-builders, live-stores dhe metrics-generators, jo për distributor që shkruan records në Kafka. Tempo 3.1 e bën gjithashtu producer compression të konfigurueshëm. Distributor tani mund të përdorë none, gzip, snappy, lz4 ose zstd. Nëse nuk vendoset asnjë opsion, Kafka client përdor snappy si default. Grafana Labs thotë se kjo ka rëndësi për Kafka-compatible backends që pranojnë vetëm një codec, duke përmendur Azure Event Hubs, që mbështet Kafka protocol por pranon vetëm gzip.
Ndryshimi më i rëndësishëm për security është query-based trace redaction. Redaction do të thotë heqje e përhershme e të dhënave nga traces të ruajtura. Tempo 3.0 shtoi redaction, por tempo-cli redact pranonte vetëm trace IDs, kështu që operators duhej të rendisnin çdo trace të prekur. Tempo 3.1 u lejon operators të paraqesin një TraceQL query në vend të kësaj. TraceQL është query language i Tempo për trace data. Grafana Labs jep një shembull të përputhjes së një span attribute që përmban informacion personal të rrjedhur dhe rekomandon të fillohet me --dry-run, që numëron çfarë do të hiqej pa ndryshuar blocks. Command printon një batch ID dhe job count, ndërsa metrics per-tenant për job counts dhe traces të përputhura ose të hequra shfaqen në rreshtin Redaction të dashboard Backend Work të përfshirë me monitoring mixin të Tempo.
Kjo fuqi shtesë vjen me risk. Grafana Labs deklaron se ekzekutimi pa --dry-run rishkruan blocks dhe nuk mund të zhbëhet. Për të ulur deletion aksidental, accepted query syntax është kufizuar qëllimisht për momentin në një spanset filter të vetëm me equality comparisons ndaj attributes resource.* dhe span.*, të kombinuara me && dhe ||. Operators mund të përdorin gjithashtu --start dhe --end për të kufizuar time range, duke përdorur now, një offset si now-7d ose një RFC3339 timestamp. Kjo mund t’i bëjë jobs më të shpejta dhe më efikase në installations me volum të lartë, sepse Tempo ndalon compaction për një tenant ndërsa redaction po aplikohet. Grafana Labs paralajmëron se këto time range options duhet të përdoren vetëm pasi çdo scheduler dhe worker në një cell të jetë duke ekzekutuar të paktën Tempo 3.1, sepse një worker më i vjetër e injoron window dhe heq çdo query match në secilin block që merr, pa error dhe pa recovery path.
Tempo 3.1 ndryshon gjithashtu TraceQL metrics, që janë ad hoc metrics të pyetura drejtpërdrejt nga trace data. Sampling-aware metrics queries shtojnë një hint eksperimental with(extrapolate=true). Sampling do të thotë të ruash vetëm një pjesë të trace stream, për shembull 50 për qind të traces. Pa correction, një query rate() mbi 50 për qind sampled data raporton rreth gjysmën e traffic themelor. Hint i ri lexon sampling rate nga OpenTelemetry probability sampling field në tracestate, kur është i pranishëm, dhe i shkallëzon spans sipas kësaj. Me 50 për qind sampling, çdo span i ruajtur numërohet si dy, kështu që një query që përputh 1,000 spans raporton 2,000. Spans pa një sampling rate të regjistruar numërohen si një, gjë që e bën partial adoption të sigurt. Grafana Labs thotë se hint kërkon vParquet4 blocks ose më të rinj dhe zbatohet për rate, count_over_time, sum_over_time, avg_over_time, histogram_over_time, quantile_over_time dhe compare, por jo për min_over_time ose max_over_time.
TraceQL metrics tani mund të përdorin arithmetic operators +, -, * dhe / midis dy metrics queries, kështu që një llogaritje error-rate mund të ndajë një error rate query me një total traffic query brenda vetë TraceQL. Çdo sub-query ka nevojë për parentheses, dhe scalars mund të përdoren në secilën anë, si për shembull shumëzimi i një duration quantile me 1000 për ta shprehur në milliseconds. Kur queries janë grouped, series kombinohen vetëm kur label sets të tyre përputhen saktësisht; një anë pa labels transmetohet në çdo series në anën tjetër. Hint extrapolate mund të aplikohet në të gjithë arithmetic expression, por Grafana Labs thotë se vendosja e with(...) brenda një sub-query është syntax error.
Metrics queries duhet të bëhen gjithashtu më të shpejta ndërsa shkruhen të dhëna të reja. Span-only fetch path i prezantuar eksperimentalisht në Tempo 3.0 tani është aktivizuar si default për vParquet5 blocks, default block format në Tempo 3.1. Apache Parquet është një storage format i bazuar në columns, i projektuar për lexime analitike efikase. Queries që nuk kanë nevojë për strukturë të plotë trace mund të përpunojnë individual spans në vend të whole traces, duke ulur latency dhe memory use. Grafana Labs raporton se në një test të ngrohur paraprakisht, një query e thjeshtë { } | rate() me span-only fetch të aktivizuar përfundoi në pak më shumë se gjysmën e kohës së së njëjtës query me të çaktivizuar. Operators mund të opt out per tenant ose per query.
Metrics-generator, një component opsional i Tempo që i kthen ingested spans në RED metrics (rate, errors dhe duration) dhe service graphs, merr gjithashtu disa përditësime. Një label i ri unmatched_span_kind në expired edges counter ndihmon të shpjegohen service-map links që mungojnë duke treguar se cila anë e një client-server span pair nuk arriti. Tempo 3.1 njeh gjithashtu ndryshimin e OpenTelemetry semantic convention nga db.system në db.system.name, duke i pranuar të dyja për identifikimin e database requests dhe emërtimin e virtual nodes. Nëse të dy attributes janë të pranishëm, db.system ka përparësi, duke shmangur riemërtime të dashboard dhe alert pas software development kit upgrades. Grafana Labs thotë gjithashtu se span-metrics dhe service-graphs processors tani huazojnë pooled label buffers në vend që të alokojnë të rinj çdo herë, me steady-state service-graphs benchmarks që raportojnë zero allocations per operation.
Për leximin e individual traces, Tempo 3.1 shton span pruning eksperimental në endpoint trace-by-ID v2.