Tracing: wat is het, principes en gegevensverzameling

Wat is tracing in monitoring

Tracing is een methode van gedistribueerde observatie waarbij elk binnenkomend verzoek wordt gevolgd door alle diensten en componenten van het systeem. In tegenstelling tot metrieken, die geaggregeerde waarden tonen (gemiddelde responstijd, aantal fouten), behoudt tracing de volledige context van een specifiek verzoek.

Elke verwerkingsstap — een database-oproep, een HTTP-verzoek naar een andere microservice, het uitvoeren van een achtergrondtaak — wordt geregistreerd als een afzonderlijke eenheid met een tijdstempel, status en attributen. Volgens gegevens van Google Dapper (oorspronkelijke publicatie uit 2010), stelt tracing in staat om vertragingen in gedistribueerde systemen te lokaliseren met de precisie van een enkele aanroep.

Tracing is vooral belangrijk voor mobiele applicaties waar de back-end uit tientallen microservices bestaat. Een gebruikersactie — bijvoorbeeld inloggen op een account — kan door API Gateway, de authenticatiedienst, de database en de Push-dienst gaan. Zonder trace is het praktisch onmogelijk te bepalen welke component het antwoord vertraagt.

Spans en traces: basis gegevensstructuur

De basiseenheid van tracing is een span. Elke span vertegenwoordigt een enkele logische operatie: een HTTP-verzoek, een SQL-query, een gRPC-aanroep, JSON-serialisatie. Een span bevat een unieke identificatie, een ouderidentificatie, de naam van de operatie, starttijd, duur, status en een set attributen.

Hiërarchie van spans in een trace

Alle spans die betrekking hebben op een enkel root-verzoek worden verenigd in een trace. De root-span vertegenwoordigt het ingangspunt — een HTTP-verzoek van de mobiele client naar de API. Kind-spans vormen een boom waarin elke span naar de ouder verwijst via het veld parent_span_id.

De duur van een trace is gelijk aan de som van de unieke tijdssegmenten van alle spans. Als twee kind-spans parallel worden uitgevoerd, wordt hun tijd niet opgeteld — dit is cruciaal voor een correcte analyse van vertragingen veroorzaakt door parallelle aanroepen van microservices.

Attributen en gebeurtenissen van een span

Elke span kan attributen bevatten — sleutel-waardeparen met metainformatie: URL van het verzoek, gebruikers-ID, API-versie, hostnaam. Attributen worden gebruikt voor het filteren en groeperen van traces. Naast attributen ondersteunt span gebeurtenissen — tijdstempels met een tekstuele beschrijving, bijvoorbeeld „cachemisser” of „poging tot herverbinding”.

Hoe werkt distributed tracing

Distributed tracing lost het probleem op van het verbinden van spans die in verschillende processen en op verschillende machines worden gecreëerd. Het mechanisme is gebaseerd op contextoverdracht: bij het aanroepen van dienst B vanuit dienst A wordt aan het uitgaande verzoek een header toegevoegd met de identificatie van de huidige trace en de ouder-span.

Standaardprotocollen voor contextoverdracht — W3C Trace Context (headers traceparent en tracestate) en Zipkin B3 (headers X-B3-TraceId, X-B3-SpanId). W3C Trace Context is in 2021 door het W3C-consortium als standaard aangenomen en wordt ondersteund door alle belangrijke telemetrieleveranciers.

Bij ontvangst van het verzoek haalt dienst B de trace_id uit de header en creëert een kind-span met deze trace_id. Zo worden na voltooiing van het verzoek alle spans uit verschillende diensten aan de kant van de collector in één trace verenigd. Hiervoor moet elke dienst met dezelfde tracingbibliotheek worden geïnstrumenteerd.

Contextoverdracht in microservices

In mobiele ontwikkeling omvat contextoverdracht niet alleen de back-end, maar ook de client-serverinteractie. Een mobiele applicatie kan trace_id in de header van elk API-verzoek sturen, waardoor de clientactie kan worden gekoppeld aan de serververwerking. OpenTelemetry SDK voor iOS en Android ondersteunt het automatisch creëren en doorgeven van trace-context via HTTP-cliënten.

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

De gepresenteerde interceptor in Kotlin creëert een span voor elk HTTP-verzoek naar de server. De oudercontext wordt doorgegeven vanuit de aanroepende code via Context.current(), waardoor de client-side trace kan worden gekoppeld aan de server-side trace.

Implementatie van tracing via OpenTelemetry

OpenTelemetry — de facto standaard voor het verzamelen van trace-gegevens. Het biedt een uniforme API voor het genereren van spans, automatische instrumentatie van populaire bibliotheken en een flexibel mechanisme voor het exporteren van gegevens naar verschillende back-ends: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Automatische instrumentatie

OpenTelemetry ondersteunt het automatisch creëren van spans voor populaire frameworks: Spring Boot, Ktor, Flask, Express, gRPC. De ontwikkelaar hoeft alleen maar een afhankelijkheid aan het project toe te voegen, en de bibliotheek onderschept zelfstandig inkomende en uitgaande verzoeken. Auto-instrumentation voor Java gebruikt javaagent, dat bytecode on-the-fly wijzigt zonder de broncode te veranderen.

Voor mobiele platforms biedt OpenTelemetry Swift SDK en Kotlin SDK. Ze creëren automatisch spans voor netwerkverzoeken (URLSession, OkHttp), databasewerk (CoreData, Room) en achtergrondtaken. De ontwikkelaar kan aangepaste spans toevoegen voor de bedrijfslogica.

Gegevensexport

Verzamelde spans worden naar de collector gestuurd via het OTLP-protocol (OpenTelemetry Protocol). De collector kan gegevens bufferen, filteren en doorsturen naar een of meerdere opslagsystemen. Volgens de OpenTelemetry-documentatie bedraagt de typische vertraging van het genereren van een span tot de weergave ervan op het dashboard 2–5 seconden bij gebruik van 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()

Code in Swift activeert de automatische instrumentatie van de netwerklaag en creëert een aangepaste span voor de bewerking van het ophalen van het gebruikersprofiel. Het attribuut user.id maakt het later mogelijk om traces op een specifieke gebruiker te filteren.

Samplingstrategieën voor traces

In hoogbelaste systemen is het traceren van elk verzoek onmogelijk — dit zou een onaanvaardbare belasting van opslag en netwerk veroorzaken. Sampling lost dit probleem op door slechts een deel van de traces op te slaan. De keuze van de strategie heeft directe invloed op de volledigheid van de gegevens en de infrastructuurkosten.

Head-based sampling

De beslissing om een trace op te slaan wordt genomen op het moment van creatie — in de root-span. De eenvoudigste en meest voorkomende aanpak: een vast percentage van de verzoeken (bijv. 5%) wordt opgeslagen, de rest wordt weggegooid. Nadeel — er kan niet worden gegarandeerd dat zeldzame fouten worden vastgelegd. Probability sampler in OpenTelemetry ondersteunt het instellen van de waarschijnlijkheid van 0.0 tot 1.0.

Tail-based sampling

De beslissing wordt uitgesteld totdat alle spans van een trace zijn voltooid. De analysator evalueert of de trace fouten, tijdoverschrijding of interessante attributen bevat en slaat deze pas daarna op. Deze aanpak vereist buffering van alle spans in de collector, wat het geheugengebruik verhoogt. Volgens gegevens van Grafana Labs is tail-based sampling 40–60% efficiënter wat betreft de verhouding „prijs voor bruikbare gegevens” in systemen met zeldzame maar kritieke fouten.

Verschil tussen tracing en loggen

Loggen registreert afzonderlijke gebeurtenissen met een belangrijkheidsniveau (info, warn, error), maar verbindt ze niet in de context van een enkel verzoek. Tracing daarentegen creëert een gestructureerde boom van operaties die bij één end-to-end verzoek horen. In de praktijk sluiten deze twee benaderingen elkaar niet uit, maar vullen ze elkaar aan.

Logs zijn effectief voor gedetailleerde analyse van een specifieke fout: de ontwikkelaar ziet het exacte bericht, de stacktrace en de waarden van variabelen. Tracing geeft antwoord op de vraag „waarom duurt een verzoek 5 seconden” — het laat zien welke microservice of aanroep de meeste tijd in beslag nam. Volgens gegevens van Honeycomb (2024) vinden teams die tracing samen met loggen gebruiken de hoofdoorzaak van incidenten 2,3 keer sneller.

De moderne benadering — observability — combineert traces, metrieken en logs in één systeem. OpenTelemetry ondersteunt correlatie tussen deze drie signalen: elke span kan verwijzingen naar gerelateerde logs bevatten, en metrieken kunnen worden gemarkeerd met trace_id om naar specifieke traces te navigeren.