Tracing: ce este, principii și colectarea datelor

Ce este tracing-ul în monitorizare

Tracing-ul este o metodă de observare distribuită în care fiecare cerere de intrare este urmărită prin toate serviciile și componentele sistemului. Spre deosebire de metrici, care arată valori agregate (timp mediu de răspuns, numărul de erori), tracing-ul păstrează contextul complet al unei cereri specifice.

Fiecare pas de procesare — apel de bază de date, cerere HTTP către un alt microserviciu, executarea unei sarcini de fundal — este înregistrat ca o unitate separată cu marcaj temporal, stare și atribute. Conform datelor Google Dapper (publicația originală din 2010), tracing-ul permite localizarea întârzierilor în sistemele distribuite cu precizia unui singur apel.

Tracing-ul este deosebit de important pentru aplicațiile mobile, unde backend-ul constă din zeci de microservicii. Acțiunea utilizatorului — de exemplu, autentificarea în cont — poate trece prin API Gateway, serviciul de autentificare, baza de date și serviciul Push. Fără trace, este practic imposibil de determinat care componentă încetinește răspunsul.

Span-uri și trace-uri: structura de bază a datelor

Unitatea de bază a tracing-ului este span-ul. Fiecare span reprezintă o singură operație logică: o cerere HTTP, o interogare SQL, un apel gRPC, o serializare JSON. Span-ul conține un identificator unic, un identificator părinte, numele operației, timpul de începere, durata, starea și un set de atribute.

Ierarhia span-urilor într-un trace

Toate span-urile referitoare la o singură cerere rădăcină se unesc într-un trace. Span-ul rădăcină (root span) reprezintă punctul de intrare — o cerere HTTP de la clientul mobil către API. Span-urile copil creează un arbore în care fiecare span se referă la părinte prin câmpul parent_span_id.

Durata unui trace este egală cu suma duratelor segmentelor temporale unice ale tuturor span-urilor. Dacă două span-uri copil se execută în paralel, timpul lor nu se însumează — acest lucru este critic pentru analiza corectă a întârzierilor cauzate de apelurile paralele ale microserviciilor.

Atributele și evenimentele span-ului

Fiecare span poate conține atribute — perechi cheie-valoare cu metainformații: URL-ul cererii, ID-ul utilizatorului, versiunea API, numele gazdei. Atributele sunt utilizate pentru filtrarea și gruparea trace-urilor. Pe lângă atribute, span-ul suportă evenimente — marcaje temporale cu descriere text, de exemplu „ratare cache” sau „încercare de reconectare”.

Cum funcționează distributed tracing

Distributed tracing rezolvă problema conectării span-urilor care sunt create în procese diferite și pe mașini diferite. Mecanismul se bazează pe transmiterea contextului: la apelarea serviciului B din serviciul A, în cererea de ieșire se adaugă un antet cu identificatorul trace-ului curent și al span-ului părinte.

Protocoalele standard de transmitere a contextului — W3C Trace Context (antetele traceparent și tracestate) și Zipkin B3 (antetele X-B3-TraceId, X-B3-SpanId). W3C Trace Context a fost adoptat ca standard de consorțiul W3C în 2021 și este suportat de toți furnizorii principali de telemetrie.

La primirea cererii, serviciul B extrage trace_id din antet și creează un span copil cu acest trace_id. Astfel, după finalizarea cererii, toate span-urile din diferite servicii se unesc într-un singur trace la nivelul colectorului. Pentru aceasta, fiecare serviciu trebuie să fie instrumentat cu aceeași bibliotecă de tracing.

Transmiterea contextului în microservicii

În dezvoltarea mobilă, transmiterea contextului acoperă nu doar backend-ul, ci și interacțiunea client-server. Aplicația mobilă poate trimite trace_id în antetul fiecărei cereri API, permițând conexiunea acțiunii clientului cu procesarea pe server. OpenTelemetry SDK pentru iOS și Android suportă crearea și transmiterea automată a contextului de trace prin clienții HTTP.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

Interceptorul prezentat în Kotlin creează un span pentru fiecare cerere HTTP către server. Contextul părinte este transmis din codul apelant prin Context.current(), ceea ce permite conexiunea trace-ului clientului cu trace-ul serverului.

Implementarea tracing-ului prin OpenTelemetry

OpenTelemetry — standardul de facto pentru colectarea datelor de trace. Oferă o API unificată pentru generarea span-urilor, instrumentarea automată a bibliotecilor populare și un mecanism flexibil de export al datelor către diferite backend-uri: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Instrumentarea automată

OpenTelemetry suportă crearea automată de span-uri pentru framework-uri populare: Spring Boot, Ktor, Flask, Express, gRPC. Dezvoltatorul trebuie doar să adauge o dependență în proiect, iar biblioteca interceptează independent cererile de intrare și de ieșire. Auto-instrumentation pentru Java utilizează javaagent, care modifică bytecode-ul din zbor fără a modifica sursa.

Pentru platformele mobile, OpenTelemetry oferă Swift SDK și Kotlin SDK. Acestea creează automat span-uri pentru cererile de rețea (URLSession, OkHttp), lucrul cu baza de date (CoreData, Room) și sarcinile de fundal. Dezvoltatorul poate adăuga span-uri personalizate pentru logica de business.

Exportul datelor

Span-urile colectate sunt trimise colectorului prin protocolul OTLP (OpenTelemetry Protocol). Colectorul poate bufferiza, filtra și redirecționa datele către unul sau mai multe sisteme de stocare. Conform documentației OpenTelemetry, întârzierea tipică de la generarea span-ului până la afișarea acestuia în dashboard este de 2–5 secunde la utilizarea exportului gRPC.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Codul în Swift activează instrumentarea automată a stratului de rețea și creează un span personalizat pentru operația de preluare a profilului utilizatorului. Atributul user.id permite filtrarea ulterioară a trace-urilor după un anumit utilizator.

Strategii de eșantionare a trace-urilor

În sistemele cu trafic ridicat, nu este posibilă trasarea fiecărei cereri — aceasta ar crea o sarcină inacceptabilă asupra stocării și rețelei. Eșantionarea rezolvă această problemă, salvând doar o parte din trace-uri. Alegerea strategiei influențează direct completitudinea datelor și costul infrastructurii.

Head-based sampling

Decizia de salvare a trace-ului se ia în momentul creării acestuia — în span-ul rădăcină. Cea mai simplă și răspândită abordare: un procent fix de cereri (de exemplu, 5%) este salvat, restul sunt aruncate. Dezavantajul — nu se poate garanta că erorile rare vor fi capturate. Probability sampler în OpenTelemetry suportă setarea probabilității de la 0.0 la 1.0.

Tail-based sampling

Decizia este amânată până la finalizarea tuturor span-urilor trace-ului. Analizatorul evaluează dacă trace-ul conține erori, depășirea timpului sau atribute interesante și abia apoi îl salvează. Această abordare necesită bufferizarea tuturor span-urilor în colector, ceea ce crește consumul de memorie. Conform datelor Grafana Labs, tail-based sampling este cu 40–60% mai eficient din punct de vedere al raportului „preț pentru date utile” în sistemele cu erori rare dar critice.

Diferența dintre tracing și logare

Logarea înregistrează evenimente separate cu nivel de importanță (info, warn, error), dar nu le leagă în contextul unei singure cereri. Tracing-ul, dimpotrivă, creează un arbore structurat de operații care aparțin unei cereri end-to-end. În practică, aceste două abordări nu se exclud, ci se completează reciproc.

Logurile sunt eficiente pentru analiza detaliată a unei erori specifice: dezvoltatorul vede mesajul exact, stiva de apeluri, valorile variabilelor. Tracing-ul răspunde la întrebarea „de ce cererea durează 5 secunde” — arată care microserviciu sau apel a ocupat cel mai mult timp. Conform datelor Honeycomb (2024), echipele care utilizează tracing-îl împreună cu logarea găsesc cauza principală a incidentelor de 2,3 ori mai repede.

Abordarea modernă — observability — combină trace-urile, metricile și logurile într-un singur sistem. OpenTelemetry suportă corelația între aceste trei semnale: fiecare span poate conține referințe la logurile asociate, iar metricile pot fi etichetate cu trace_id pentru a naviga la trace-uri specifice.