Tracing: mi ez, elvek és adatgyűjtés

Mi az a tracing a monitorozásban

A tracing egy elosztott megfigyelési módszer, ahol minden beérkező kérés követve van a rendszer összes szolgáltatásán és komponensén keresztül. A metrikáktól eltérően, amelyek összesített értékeket mutatnak (átlagos válaszidő, hibák száma), a tracing megtartja egy adott kérés teljes kontextusát.

A feldolgozás minden lépése — adatbázis-hívás, HTTP kérés egy másik mikroszolgáltatáshoz, háttérfeladat végrehajtása — külön egységként kerül rögzítésre időbélyeggel, állapottal és attribútumokkal. A Google Dapper adatai szerint (eredeti publikáció 2010-ből), a tracing lehetővé teszi a késleltetések lokalizálását elosztott rendszerekben egyetlen hívás pontosságával.

A tracing különösen fontos a mobilalkalmazások számára, ahol a backend több tucat mikroszolgáltatásból áll. Egy felhasználói művelet — például bejelentkezés a fiókba — áthaladhat az API Gateway-en, a hitelesítési szolgáltatáson, az adatbázison és a Push szolgáltatáson. Trace nélkül gyakorlatilag lehetetlen meghatározni, hogy melyik komponens lassítja a választ.

Spánok és trace-ek: alapvető adatstruktúra

A tracing alapegysége a span. Minden span egyetlen logikai műveletet reprezentál: HTTP kérés, SQL lekérdezés, gRPC hívás, JSON szerializáció. A span tartalmaz egy egyedi azonosítót, szülő azonosítót, művelet nevet, kezdési időt, időtartamot, állapotot és attribútumok halmazát.

Spánok hierarchiája egy trace-ben

Az egy gyökérkéréshez tartozó összes span egy trace-ben egyesül. A gyökér span (root span) a belépési pontot reprezentálja — egy HTTP kérést a mobil klienstől az API-hoz. A gyermek spánok egy fát alkotnak, ahol minden span a parent_span_id mezőn keresztül hivatkozik a szülőre.

Egy trace időtartama megegyezik az összes span egyedi időszegmenseinek összegével. Ha két gyermek span párhuzamosan hajtódik végre, az idejük nem adódik össze — ez kritikus a mikroszolgáltatások párhuzamos hívásai által okozott késleltetések helyes elemzéséhez.

Span attribútumok és események

Minden span tartalmazhat attribútumokat — kulcs-érték párokat metainformációkkal: kérés URL-je, felhasználó ID, API verzió, hoszt név. Az attribútumokat a trace-ek szűrésére és csoportosítására használják. Az attribútumok mellett a span támogatja az eseményeket — időbélyegeket szöveges leírással, például „gyorsítótár kihagyás” vagy „kapcsolat újrapróbálkozása”.

Hogyan működik a distributed tracing

A distributed tracing megoldja a különböző folyamatokban és különböző gépeken létrehozott spánok összekapcsolásának problémáját. A mechanizmus kontextus átadáson alapul: a B szolgáltatás A szolgáltatásból történő hívásakor a kimenő kéréshez egy fejléc kerül hozzáadásra az aktuális trace és a szülő span azonosítójával.

A kontextus átadás szabványos protokolljai — W3C Trace Context (traceparent és tracestate fejlécek) és Zipkin B3 (X-B3-TraceId, X-B3-SpanId fejlécek). A W3C Trace Context-et a W3C konzorcium 2021-ben fogadta el szabványként, és az összes fő telemetriai szolgáltató támogatja.

A kérés fogadásakor a B szolgáltatás kinyeri a trace_id-t a fejlécből, és létrehoz egy gyermek spant ezzel a trace_id-val. Így a kérés befejezése után az összes spán a különböző szolgáltatásokból egyetlen trace-ben egyesül a gyűjtő oldalán. Ehhez minden szolgáltatásnak ugyanazzal a tracing könyvtárral kell instrumentáltnak lennie.

Kontextus átadás mikroszolgáltatásokban

A mobilfejlesztésben a kontextus átadás nem csak a backendet fedi le, hanem a kliens-szerver interakciót is. A mobilalkalmazás trace_id-t küldhet minden API kérés fejlécében, lehetővé téve a kliens művelet és a szerveroldali feldolgozás összekapcsolását. Az iOS és Android OpenTelemetry SDK-ja támogatja a trace kontextus automatikus létrehozását és továbbítását HTTP klienseken keresztül.

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

A bemutatott Kotlin interceptor minden HTTP kéréshez létrehoz egy spant a szerver felé. A szülő kontextus a hívó kódból kerül továbbításra a Context.current() segítségével, ami lehetővé teszi a kliens oldali trace és a szerver oldali trace összekapcsolását.

A tracing megvalósítása OpenTelemetry-n keresztül

Az OpenTelemetry a trace adatok gyűjtésének de facto szabványa. Egységes API-t biztosít a spánok generálásához, a népszerű könyvtárak automatikus instrumentálását és egy rugalmas adatexportáló mechanizmust különböző backendekhez: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Automatikus instrumentálás

Az OpenTelemetry támogatja a spánok automatikus létrehozását népszerű keretrendszerekhez: Spring Boot, Ktor, Flask, Express, gRPC. A fejlesztőnek csak egy függőséget kell hozzáadnia a projekthez, és a könyvtár önállóan elfogja a beérkező és kimenő kéréseket. A Java Auto-instrumentation egy javaagent-et használ, amely menet közben módosítja a bytecode-ot anélkül, hogy a forráskódot megváltoztatná.

Mobil platformokhoz az OpenTelemetry Swift SDK-t és Kotlin SDK-t biztosít. Ezek automatikusan létrehoznak spánokat hálózati kérésekhez (URLSession, OkHttp), adatbázis munkához (CoreData, Room) és háttérfeladatokhoz. A fejlesztő egyedi spánokat adhat hozzá az üzleti logikához.

Adatok exportálása

A összegyűjtött spánok az OTLP (OpenTelemetry Protocol) protokollon keresztül kerülnek a gyűjtőbe. A gyűjtő pufferelheti, szűrheti és továbbíthatja az adatokat egy vagy több tárolórendszerbe. Az OpenTelemetry dokumentációja szerint a tipikus késleltetés a span létrehozásától a dashboardon való megjelenésig 2–5 másodperc gRPC exportálás használata esetén.

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

A Swift kód aktiválja a hálózati réteg automatikus instrumentálását, és létrehoz egy egyedi spant a felhasználói profil lekérésének műveletéhez. A user.id attribútum lehetővé teszi a trace-ek későbbi szűrését egy adott felhasználó szerint.

Trace-ek mintavételezési stratégiái

Magasan terhelt rendszerekben lehetetlen minden kérést trace-elni — ez elfogadhatatlan terhelést okozna a tárolón és a hálózaton. A mintavételezés megoldja ezt a problémát azzal, hogy csak a trace-ek egy részét menti el. A stratégia választása közvetlenül befolyásolja az adatok teljességét és az infrastruktúra költségeit.

Head-based sampling

A trace mentéséről szóló döntés a létrehozás pillanatában történik — a gyökér spanban. A legegyszerűbb és legelterjedtebb megközelítés: a kérések rögzített százaléka (például 5%) kerül mentésre, a többi eldobásra kerül. Hátránya — nem garantálható, hogy a ritka hibák rögzítésre kerülnek. Az OpenTelemetry Probability sampler-je támogatja a valószínűség beállítását 0.0 és 1.0 között.

Tail-based sampling

A döntés elhalasztásra kerül a trace összes spánjának befejeződéséig. Az elemző kiértékeli, hogy a trace tartalmaz-e hibákat, időtúllépést vagy érdekes attribútumokat, és csak azután menti el. Ez a megközelítés az összes span pufferelését igényli a gyűjtőben, ami növeli a memóriafogyasztást. A Grafana Labs adatai szerint a tail-based sampling 40–60%-kal hatékonyabb az „ár a hasznos adatokért” arány tekintetében a ritka, de kritikus hibákkal rendelkező rendszerekben.

Különbség a tracing és a naplózás között

A naplózás különálló eseményeket rögzít fontossági szinttel (info, warn, error), de nem köti össze őket egyetlen kérés kontextusában. A tracing ezzel szemben strukturált műveleti fát hoz létre, amely egy végpontok közötti kéréshez tartozik. A gyakorlatban ez a két megközelítés nem zárja ki egymást, hanem kiegészíti.

A naplók hatékonyak egy adott hiba részletes elemzéséhez: a fejlesztő látja a pontos üzenetet, a veremkiírást, a változók értékeit. A tracing válaszol arra a kérdésre, hogy „miért tart a kérés 5 másodpercig” — megmutatja, melyik mikroszolgáltatás vagy hívás vett igénybe a legtöbb időt. A Honeycomb (2024) adatai szerint a tracinget naplózással együtt használó csapatok 2,3-szor gyorsabban találják meg az incidensek kiváltó okát.

A modern megközelítés — observability — egyesíti a trace-eket, metrikákat és naplókat egyetlen rendszerben. Az OpenTelemetry támogatja a korrelációt e három jel között: minden span tartalmazhat hivatkozásokat kapcsolódó naplókra, és a metrikák trace_id-vel jelölhetők a konkrét trace-ekhez való navigáláshoz.