Tracing: co to je, principy a sběr dat

Co je tracing v monitorování

Tracing je metoda distribuovaného pozorování, při které je každý příchozí požadavek sledován přes všechny služby a komponenty systému. Na rozdíl od metrik, které ukazují agregované hodnoty (průměrná doba odezvy, počet chyb), tracing zachovává úplný kontext jednoho konkrétního požadavku.

Každý krok zpracování — volání databáze, HTTP požadavek na jinou mikroslužbu, provedení úlohy na pozadí — je zaznamenán jako samostatná jednotka s časovým razítkem, stavem a atributy. Podle údajů Google Dapper (původní publikace z roku 2010), tracing umožňuje lokalizovat zpoždění v distribuovaných systémech s přesností na jedno volání.

Tracing je obzvláště důležitý pro mobilní aplikace, kde backend tvoří desítky mikroslužeb. Uživatelská akce — například přihlášení k účtu — může projít přes API Gateway, autentizační službu, databázi a Push službu. Bez trace je prakticky nemožné určit, která komponenta zpomaluje odpověď.

Spany a trace: základní datová struktura

Základní jednotkou trace je span. Každý span představuje jednu logickou operaci: HTTP požadavek, SQL dotaz, volání gRPC, serializaci JSON. Span obsahuje jedinečný identifikátor, identifikátor rodiče, název operace, čas zahájení, dobu trvání, stav a sadu atributů.

Hierarchie spanů v trace

Všechny spany týkající se jednoho kořenového požadavku se spojují v trace. Kořenový span (root span) představuje vstupní bod — HTTP požadavek od mobilního klienta k API. Dětské spany tvoří strom, kde každý span odkazuje na rodiče polem parent_span_id.

Doba trvání trace se rovná součtu dob trvání jedinečných časových úseků všech spanů. Pokud se dva dětské spany provádějí paralelně, jejich čas se nesčítá — to je kritické pro správnou analýzu zpoždění způsobených paralelními voláními mikroslužeb.

Atributy a události spanu

Každý span může obsahovat atributy — páry klíč-hodnota s metainformacemi: URL požadavku, ID uživatele, verze API, název hostitele. Atributy se používají k filtrování a seskupování trace. Kromě atributů span podporuje události — časová razítka s textovým popisem, například „výpadek mezipaměti“ nebo „pokus o opětovné připojení“.

Jak funguje distributed tracing

Distributed tracing řeší problém propojování spanů, které jsou vytvářeny v různých procesech a na různých strojích. Mechanismus je založen na kontextovém předávání: při volání služby B ze služby A je k odchozímu požadavku přidána hlavička s identifikátorem aktuálního trace a rodičovského spanu.

Standardní protokoly pro předávání kontextu — W3C Trace Context (hlavičky traceparent a tracestate) a Zipkin B3 (hlavičky X-B3-TraceId, X-B3-SpanId). W3C Trace Context byl přijat jako standard konsorciem W3C v roce 2021 a je podporován všemi hlavními poskytovateli telemetrie.

Při přijetí požadavku služba B extrahuje trace_id z hlavičky a vytvoří dětský span s tímto trace_id. Po dokončení požadavku se všechny spany z různých služeb spojí do jednoho trace na straně kolektoru. K tomu musí být každá služba instrumentována stejnou knihovnou pro tracing.

Kontextové předávání v mikroslužbách

V mobilním vývoji kontextové předávání zahrnuje nejen backend, ale i interakci klient-server. Mobilní aplikace může odesílat trace_id v hlavičce každého API požadavku, což umožňuje propojení akce klienta se zpracováním na serveru. OpenTelemetry SDK pro iOS a Android podporuje automatické vytváření a předávání trace kontextu přes HTTP klienty.

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

Prezentovaný interceptor v Kotlinu vytváří span pro každý HTTP požadavek na server. Rodičovský kontext je předáván z volajícího kódu přes Context.current(), což umožňuje propojení trace na straně klienta s trace na straně serveru.

Implementace tracingu přes OpenTelemetry

OpenTelemetry — de facto standard pro sběr dat trace. Poskytuje jednotné API pro generování spanů, automatickou instrumentaci populárních knihoven a flexibilní mechanismus exportu dat do různých backendů: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Automatická instrumentace

OpenTelemetry podporuje automatické vytváření spanů pro populární frameworky: Spring Boot, Ktor, Flask, Express, gRPC. Vývojář stačí přidat závislost do projektu a knihovna samostatně zachycuje příchozí a odchozí požadavky. Auto-instrumentation pro Javu používá javaagent, který modifikuje bytecode za běhu bez změny zdrojového kódu.

Pro mobilní platformy OpenTelemetry poskytuje Swift SDK a Kotlin SDK. Automaticky vytvářejí spany pro síťové požadavky (URLSession, OkHttp), práci s databází (CoreData, Room) a úlohy na pozadí. Vývojář může přidávat vlastní spany pro obchodní logiku.

Export dat

Shromážděné spany jsou odesílány do kolektoru pomocí protokolu OTLP (OpenTelemetry Protocol). Kolektor může data bufferovat, filtrovat a přesměrovávat do jednoho nebo více úložných systémů. Podle dokumentace OpenTelemetry, typické zpoždění od vygenerování spanu po jeho zobrazení na dashboardu je 2–5 sekund při použití gRPC exportu.

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

Kód ve Swift aktivuje automatickou instrumentaci síťové vrstvy a vytváří vlastní span pro operaci načtení profilu uživatele. Atribut user.id umožňuje pozdější filtrování trace podle konkrétního uživatele.

Strategie vzorkování trace

Ve vysoce zatížených systémech není možné sledovat každý požadavek — to by vytvořilo nepřijatelné zatížení úložiště a sítě. Vzorkování řeší tento problém ukládáním pouze části trace. Výběr strategie přímo ovlivňuje úplnost dat a náklady na infrastrukturu.

Head-based sampling

Rozhodnutí o uložení trace se provádí v okamžiku jeho vytvoření — v kořenovém spanu. Nejjednodušší a nejrozšířenější přístup: pevné procento požadavků (např. 5%) je uloženo, zbytek je zahozen. Nevýhoda — nelze zaručit, že vzácné chyby budou zachyceny. Probability sampler v OpenTelemetry podporuje nastavení pravděpodobnosti od 0,0 do 1,0.

Tail-based sampling

Rozhodnutí je odloženo až do dokončení všech spanů trace. Analyzátor vyhodnocuje, zda trace obsahuje chyby, překročení času nebo zajímavé atributy, a teprve poté jej uloží. Tento přístup vyžaduje bufferování všech spanů v kolektoru, což zvyšuje spotřebu paměti. Podle údajů Grafana Labs je tail-based sampling o 40–60% efektivnější z hlediska poměru „cena za užitečná data“ v systémech se vzácnými, ale kritickými chybami.

Rozdíl mezi tracingem a logováním

Logování zaznamenává jednotlivé události s úrovní důležitosti (info, warn, error), ale nespojuje je v kontextu jednoho požadavku. Tracing naopak vytváří strukturovaný strom operací patřících k jednomu end-to-end požadavku. V praxi se tyto dva přístupy nevylučují, ale doplňují.

Logy jsou účinné pro detailní analýzu konkrétní chyby: vývojář vidí přesnou zprávu, zásobník volání, hodnoty proměnných. Tracing odpovídá na otázku „proč požadavek trvá 5 sekund“ — ukazuje, která mikroslužba nebo volání zabralo nejvíce času. Podle údajů Honeycomb (2024), týmy používající tracing společně s logováním nacházejí hlavní příčinu incidentů 2,3krát rychleji.

Moderní přístup — observability — spojuje trace, metriky a logy do jednoho systému. OpenTelemetry podporuje korelaci mezi těmito třemi signály: každý span může obsahovat odkazy na související logy a metriky mohou být označeny trace_id pro přechod ke konkrétním trace.