Tracing: vad det är, principer och datainsamling

Vad är tracing inom övervakning

Tracing är en metod för distribuerad observation där varje inkommande förfrågan spåras genom alla tjänster och komponenter i systemet. Till skillnad från mätvärden, som visar aggregerade värden (genomsnittlig svarstid, antal fel), bevarar tracing den fullständiga kontexten för en specifik förfrågan.

Varje bearbetningssteg — databasanrop, HTTP-förfrågan till en annan mikrotjänst, utförande av en bakgrundsuppgift — registreras som en separat enhet med tidsstämpel, status och attribut. Enligt uppgifter från Google Dapper(originalpublikation från 2010), gör tracing det möjligt att lokalisera fördröjningar i distribuerade system med precisionen av ett enda anrop.

Tracing är särskilt viktigt för mobilapplikationer där backend består av dussintals mikrotjänster. En användaråtgärd — till exempel inloggning på ett konto — kan passera genom API Gateway, autentiseringstjänsten, databasen och Push-tjänsten. Utan trace är det praktiskt taget omöjligt att avgöra vilken komponent som försenar svaret.

Spån och trace: grundläggande datastruktur

Grundenheten för tracing är ett span. Varje span representerar en enskild logisk operation: en HTTP-förfrågan, en SQL-fråga, ett gRPC-anrop, JSON-serialisering. Ett span innehåller en unik identifierare, en förälderidentifierare, operationsnamn, starttid, varaktighet, status och en uppsättning attribut.

Hierarki av spån i en trace

Alla spån som hör till en enda rotförfrågan förenas i en trace. Rotspånet (root span) representerar ingångspunkten — en HTTP-förfrågan från mobilklienten till API:t. Barnspån bildar ett träd där varje span hänvisar till föräldern via fältet parent_span_id.

Varaktigheten för en trace är lika med summan av varaktigheterna för de unika tidssegmenten för alla spån. Om två barnspån körs parallellt läggs deras tid inte ihop — detta är kritiskt för korrekt analys av fördröjningar orsakade av parallella anrop till mikrotjänster.

Attribut och händelser för span

Varje span kan innehålla attribut — nyckel-värde-par med metainformation: URL för förfrågan, användar-ID, API-version, värdnamn. Attribut används för att filtrera och gruppera trace. Förutom attribut stödjer span händelser — tidsstämplar med textbeskrivning, till exempel “cachemiss” eller “återanslutningsförsök”.

Hur distributed tracing fungerar

Distributed tracing löser problemet med att koppla samman spån som skapas i olika processer och på olika maskiner. Mekanismen bygger på kontextöverföring: när tjänst B anropas från tjänst A läggs en rubrik till i den utgående förfrågan med identifieraren för den aktuella trace och föräldraspånet.

Standardprotokoll för kontextöverföring — W3C Trace Context (rubrikerna traceparent och tracestate) och Zipkin B3 (rubrikerna X-B3-TraceId, X-B3-SpanId). W3C Trace Context antogs som standard av W3C-konsortiet 2021 och stöds av alla större telemetrileverantörer.

När tjänst B tar emot förfrågan extraherar den trace_id från rubriken och skapar ett barnspan med detta trace_id. På så sätt förenas alla spån från olika tjänster i en enda trace hos insamlaren efter att förfrågan slutförts. För detta måste varje tjänst vara instrumenterad med samma tracingbibliotek.

Kontextöverföring i mikrotjänster

Inom mobilutveckling omfattar kontextöverföring inte bara backend utan även klient-serverinteraktion. En mobilapplikation kan skicka trace_id i rubriken för varje API-förfrågan, vilket möjliggör koppling av klientåtgärden med serverbearbetningen. OpenTelemetry SDK för iOS och Android stödjer automatisk skapande och överföring av trace-kontext via HTTP-klienter.

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() }
    }
}

Den presenterade interceptor i Kotlin skapar ett span för varje HTTP-förfrågan till servern. Förälderkontexten överförs från den anropande koden via Context.current(), vilket möjliggör koppling av klient-side trace med server-side trace.

Implementering av tracing via OpenTelemetry

OpenTelemetry — de facto standard för insamling av trace-data. Det tillhandahåller ett enhetligt API för att generera spån, automatisk instrumentering av populära bibliotek och en flexibel mekanism för export av data till olika backends: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Automatisk instrumentering

OpenTelemetry stödjer automatisk skapande av spån för populära ramverk: Spring Boot, Ktor, Flask, Express, gRPC. Utvecklaren behöver bara lägga till ett beroende i projektet, och biblioteket fångar självständigt inkommande och utgående förfrågningar. Auto-instrumentation för Java använder javaagent, som modifierar bytekod i farten utan att ändra källkoden.

För mobila plattformar tillhandahåller OpenTelemetry Swift SDK och Kotlin SDK. De skapar automatiskt spån för nätverksförfrågningar (URLSession, OkHttp), databasarbete (CoreData, Room) och bakgrundsuppgifter. Utvecklaren kan lägga till anpassade spån för affärslogik.

Dataexport

Insamlade spån skickas till insamlaren via protokollet OTLP (OpenTelemetry Protocol). Insamlaren kan buffra, filtrera och omdirigera data till ett eller flera lagringssystem. Enligt OpenTelemetry-dokumentationen är den typiska fördröjningen från generering av ett span till dess visning på instrumentpanelen 2–5 sekunder vid användning av gRPC-export.

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()

Kod i Swift aktiverar automatisk instrumentering av nätverkslagret och skapar ett anpassat span för operationen att hämta användarprofil. Attributet user.id möjliggör senare filtrering av trace efter en specifik användare.

Samplingsstrategier för trace

I högbelastade system är det omöjligt att trace varje förfrågan — detta skulle skapa en oacceptabel belastning på lagring och nätverk. Sampling löser detta problem genom att endast spara en del av trace. Valet av strategi påverkar direkt datakomplettheten och infrastrukturkostnaden.

Head-based sampling

Beslutet att spara en trace tas vid skapandet — i rotspånet. Det enklaste och mest utbredda tillvägagångssättet: en fast procentsats av förfrågningarna (t.ex. 5%) sparas, resten kasseras. Nackdel — det går inte att garantera att sällsynta fel fångas upp. Probability sampler i OpenTelemetry stödjer inställning av sannolikhet från 0,0 till 1,0.

Tail-based sampling

Beslutet skjuts upp tills alla spån i en trace är slutförda. Analysatorn utvärderar om trace innehåller fel, tidsöverskridning eller intressanta attribut och sparar den först då. Detta tillvägagångssätt kräver bufring av alla spån i insamlaren, vilket ökar minnesförbrukningen. Enligt uppgifter från Grafana Labs är tail-based sampling 40–60% effektivare när det gäller förhållandet “pris för användbar data” i system med sällsynta men kritiska fel.

Skillnad mellan tracing och loggning

Loggning registrerar enskilda händelser med viktighetsnivå (info, warn, error), men kopplar inte samman dem i kontexten av en enda förfrågan. Tracing å andra sidan skapar ett strukturerat träd av operationer som tillhör en end-to-end-förfrågan. I praktiken utesluter dessa två tillvägagångssätt inte varandra utan kompletterar varandra.

Loggar är effektiva för detaljerad analys av ett specifikt fel: utvecklaren ser det exakta meddelandet, stackspårningen och variabelvärdena. Tracing svarar på frågan ”varför tar förfrågan 5 sekunder” — den visar vilken mikrotjänst eller anrop som tog mest tid. Enligt uppgifter från Honeycomb (2024), hittar team som använder tracing tillsammans med loggning grundorsaken till incidenter 2,3 gånger snabbare.

Det moderna tillvägagångssättet — observability — förenar trace, mätvärden och loggar i ett enda system. OpenTelemetry stödjer korrelation mellan dessa tre signaler: varje span kan innehålla referenser till relaterade loggar, och mätvärden kan märkas med trace_id för navigering till specifika trace.