Tracing: ano ito, mga prinsipyo at pangongolekta ng datos

Ano ang tracing sa monitoring

Tracing ay isang paraan ng distributed observation kung saan ang bawat papasok na request ay sinusubaybayan sa lahat ng serbisyo at bahagi ng system. Hindi tulad ng metrics, na nagpapakita ng pinagsama-samang halaga (average response time, bilang ng mga error), pinapanatili ng tracing ang buong konteksto ng isang partikular na request.

Bawat hakbang ng pagproseso — tawag sa database, HTTP request sa ibang microservice, pagpapatupad ng background task — ay naitala bilang hiwalay na unit na may timestamp, status at attributes. Ayon sa datos ng Google Dapper(orihinal na publikasyon noong 2010), pinapayagan ng tracing ang lokalisasyon ng mga pagkaantala sa distributed system na may katumpakan hanggang sa isang tawag.

Ang tracing ay lalong mahalaga para sa mga mobile app kung saan ang backend ay binubuo ng dose-dosenang microservice. Ang isang aksyon ng user — halimbawa, pag-login sa account — ay maaaring dumaan sa API Gateway, serbisyo ng authentication, database at Push service. Kung walang trace, halos imposibleng matukoy kung aling bahagi ang nagpapabagal sa tugon.

Mga span at trace: pangunahing istruktura ng datos

Ang pangunahing unit ng tracing ay span. Ang bawat span ay kumakatawan sa isang lohikal na operasyon: HTTP request, SQL query, gRPC tawag, JSON serialization. Ang span ay naglalaman ng natatanging identifier, parent identifier, pangalan ng operasyon, oras ng pagsisimula, tagal, status at set ng mga attribute.

Herarkiya ng mga span sa trace

Lahat ng span na nauugnay sa iisang root request ay nagsasama sa trace. Ang root span ay kumakatawan sa entry point — HTTP request mula sa mobile client patungo sa API. Ang mga child span ay bumubuo ng puno kung saan ang bawat span ay tumutukoy sa magulang sa pamamagitan ng field na parent_span_id.

Ang tagal ng trace ay katumbas ng kabuuan ng tagal ng mga natatanging segment ng oras ng lahat ng span. Kung ang dalawang child span ay isinasagawa nang magkatulad, ang kanilang oras ay hindi pinagsasama — ito ay kritikal para sa tamang pagsusuri ng mga pagkaantala na dulot ng parallel na tawag ng microservice.

Mga attribute at pangyayari ng span

Ang bawat span ay maaaring maglaman ng attributes — key-value pairs na may meta-impormasyon: URL ng request, ID ng user, bersyon ng API, pangalan ng host. Ang mga attribute ay ginagamit para sa pag-filter at paggrupo ng mga trace. Bukod sa attributes, sinusuportahan ng span ang events — mga timestamp na may tekstuwal na paglalarawan, halimbawa “cache miss” o “pagtatangkang muling kumonekta”.

Paano gumagana ang distributed tracing

Distributed tracing ay lumulutas sa problema ng pag-uugnay ng mga span na nilikha sa iba’t ibang proseso at sa iba’t ibang makina. Ang mekanismo ay batay sa paglilipat ng konteksto: kapag tumatawag ng serbisyo B mula sa serbisyo A, isang header na may identifier ng kasalukuyang trace at parent span ay idinaragdag sa papalabas na request.

Mga karaniwang protocol para sa paglilipat ng konteksto — W3C Trace Context (mga header na traceparent at tracestate) at Zipkin B3 (mga header na X-B3-TraceId, X-B3-SpanId). Ang W3C Trace Context ay pinagtibay bilang pamantayan ng W3C consortium noong 2021 at sinusuportahan ng lahat ng pangunahing provider ng telemetry.

Kapag natanggap ang request, kinukuha ng serbisyo B ang trace_id mula sa header at lumilikha ng child span na may ganitong trace_id. Sa ganitong paraan, pagkatapos makumpleto ang request, lahat ng span mula sa iba’t ibang serbisyo ay nagsasama sa isang trace sa panig ng collector. Para dito, ang bawat serbisyo ay dapat na instrumented ng parehong tracing library.

Paglilipat ng konteksto sa microservice

Sa mobile development, ang paglilipat ng konteksto ay sumasaklaw hindi lamang sa backend, kundi pati na rin sa interaksyon ng client-server. Ang mobile app ay maaaring magpadala ng trace_id sa header ng bawat API request, na nagpapahintulot sa pag-uugnay ng aksyon ng client sa pagproseso ng server. OpenTelemetry SDK para sa iOS at Android ay sumusuporta sa awtomatikong paglikha at pagpapadala ng trace context sa pamamagitan ng HTTP clients.

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

Ang ipinakitang interceptor sa Kotlin ay lumilikha ng span para sa bawat HTTP request sa server. Ang parent context ay ipinapadala mula sa tumatawag na code sa pamamagitan ng Context.current(), na nagpapahintulot sa pag-uugnay ng client-side trace sa server-side trace.

Pagpapatupad ng tracing sa pamamagitan ng OpenTelemetry

OpenTelemetry — de facto na pamantayan para sa pangongolekta ng trace data. Nagbibigay ito ng pinag-isang API para sa pagbuo ng mga span, awtomatikong instrumentasyon ng mga sikat na library at nababaluktot na mekanismo ng pag-export ng datos sa iba’t ibang backend: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Awtomatikong instrumentasyon

Sinusuportahan ng OpenTelemetry ang awtomatikong paglikha ng mga span para sa mga sikat na framework: Spring Boot, Ktor, Flask, Express, gRPC. Ang developer ay kailangan lamang magdagdag ng dependency sa proyekto, at ang library ay independiyenteng humaharang ng mga papasok at papalabas na request. Auto-instrumentation para sa Java ay gumagamit ng javaagent, na nagmo-modify ng bytecode onthe-fly nang hindi binabago ang source.

Para sa mga mobile platform, ang OpenTelemetry ay nagbibigay ng Swift SDK at Kotlin SDK. Awtomatiko silang lumilikha ng mga span para sa network requests (URLSession, OkHttp), pagtatrabaho sa database (CoreData, Room) at mga background task. Ang developer ay maaaring magdagdag ng custom na span para sa business logic.

Pag-export ng datos

Ang mga nakolektang span ay ipinapadala sa collector sa pamamagitan ng OTLP protocol (OpenTelemetry Protocol). Ang collector ay maaaring mag-buffer, mag-filter at mag-redirect ng datos sa isa o maramihang storage system. Ayon sa dokumentasyon ng OpenTelemetry, ang karaniwang pagkaantala mula sa pagbuo ng span hanggang sa pagpapakita nito sa dashboard ay 2–5 segundo kapag gumagamit ng 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()

Ang code sa Swift ay nag-a-activate ng awtomatikong instrumentasyon ng network layer at lumilikha ng custom na span para sa operasyon ng pagkuha ng profile ng user. Ang attribute na user.id ay nagpapahintulot sa pag-filter ng mga trace ayon sa partikular na user.

Mga estratehiya ng sampling ng trace

Sa mga system na may mataas na karga, imposibleng i-trace ang bawat request — ito ay lilikha ng hindi katanggap-tanggap na karga sa storage at network. Sampling ay lumulutas ng problemang ito sa pamamagitan ng pag-save lamang ng bahagi ng mga trace. Ang pagpili ng estratehiya ay direktang nakakaapekto sa pagkakumpleto ng datos at gastos ng imprastraktura.

Head-based sampling

Ang desisyon na i-save ang trace ay ginagawa sa sandali ng paglikha nito — sa root span. Ang pinakasimple at pinakakaraniwang approach: isang nakapirming porsyento ng mga request (halimbawa, 5%) ay nai-save, ang natitira ay itinatapon. Ang kahinaan — hindi magagarantiyahan na ang mga bihirang error ay mahuhuli. Probability sampler sa OpenTelemetry ay sumusuporta sa pag-set ng probability mula 0.0 hanggang 1.0.

Tail-based sampling

Ang desisyon ay ipinagpapaliban hanggang sa makumpleto ang lahat ng span ng trace. Sinusuri ng analyzer kung ang trace ay naglalaman ng mga error, paglampas sa oras o kawili-wiling attributes, at pagkatapos lamang ito i-save. Ang approach na ito ay nangangailangan ng buffering ng lahat ng span sa collector, na nagpapataas ng konsumo ng memory. Ayon sa datos ng Grafana Labs, ang tail-based sampling ay 40–60% mas mahusay sa ratio ng presyo para sa kapaki-pakinabang na datos sa mga system na may bihirang ngunit kritikal na error.

Pagkakaiba ng tracing at logging

Logging ay nagtatala ng mga hiwalay na pangyayari na may antas ng kahalagahan (info, warn, error), ngunit hindi nag-uugnay ng mga ito sa konteksto ng isang request. Ang tracing, sa kabaligtaran, ay lumilikha ng struktural na puno ng mga operasyon na kabilang sa isang end-to-end na request. Sa praktika, ang dalawang approach na ito ay hindi eksklusibo sa isa’t isa, kundi nagpupuno sa isa’t isa.

Ang mga log ay epektibo para sa detalyadong pagsusuri ng isang partikular na error: nakikita ng developer ang eksaktong mensahe, stack trace, halaga ng mga variable. Ang tracing ay sumasagot sa tanong na “bakit ang request ay tumatagal ng 5 segundo” — ipinapakita nito kung aling microservice o tawag ang tumagal ng pinakamaraming oras. Ayon sa datos ng Honeycomb (2024), ang mga team na gumagamit ng tracing kasama ng logging ay nakakahanap ng root cause ng mga insidente nang 2.3 beses na mas mabilis.

Ang modernong approach — observability — pinagsasama ang trace, metrics at log sa iisang system. Sinusuportahan ng OpenTelemetry ang correlation sa pagitan ng tatlong signal na ito: bawat span ay maaaring maglaman ng mga reference sa kaugnay na log, at ang metrics ay maaaring mamarkahan ng trace_id para sa pag-navigate sa partikular na trace.