Tracing: bu nima, tamoyillari va ma’lumot yig’ish

Monitoringda tracing nima

Tracing — taqsimlangan kuzatish usuli bo’lib, unda har bir kiruvchi so’rov tizimning barcha xizmatlari va komponentlari orqali kuzatiladi. Umumiy qiymatlarni ko‘rsatadigan metrikalardan farqli o‘laroq (o‘rtacha javob vaqti, xatolar soni), tracing bitta aniq so‘rovning to‘liq kontekstini saqlaydi.

Ishlov berishning har bir bosqichi — ma’lumotlar bazasiga chaqiriq, boshqa mikroxizmatga HTTP so‘rovi, fon topshirig‘ining bajarilishi — vaqt belgisi, status va atributlar bilan alohida birlik sifatida qayd etiladi. Google Dapper ma’lumotlariga ko‘ra (2010 yilgi asl nashr), tracing taqsimlangan tizimlarda kechikishlarni bitta chaqiriq aniqligi bilan lokalizatsiya qilish imkonini beradi.

Tracing, ayniqsa, backend’i o‘nlab mikroxizmatlardan iborat bo‘lgan mobil ilovalar uchun muhimdir. Foydalanuvchi harakati — masalan, hisobga kirish — API Gateway, autentifikatsiya xizmati, ma’lumotlar bazasi va Push xizmatidan o‘tishi mumkin. Tracesiz qaysi komponent javobni sekinlashtirayotganini aniqlash deyarli imkonsiz.

Spanlar va tracelar: asosiy ma’lumot strukturasi

Tracingning asosiy birligi span-dir. Har bir span bitta mantiqiy operatsiyani ifodalaydi: HTTP so‘rovi, SQL so‘rovi, gRPC chaqirig‘i, JSON serializatsiyasi. Span noyob identifikator, ota-ona identifikatori, operatsiya nomi, boshlanish vaqti, davomiylik, status va atributlar to‘plamini o‘z ichiga oladi.

Trace ichidagi spanlar ierarxiyasi

Bitta ildiz so‘roviga tegishli barcha spanlar trace-da birlashadi. Ildiz span (root span) kirish nuqtasini — mobil mijozdan API-ga HTTP so‘rovini ifodalaydi. Farzand spanlar daraxt hosil qiladi, unda har bir span parent_span_id maydoni orqali ota-onasiga murojaat qiladi.

Trace’ning davomiyligi barcha spanlarning noyob vaqt oralig‘lari yig‘indisiga teng. Agar ikki farzand span parallel bajarilsa, ularning vaqti umumlashtirilmaydi — bu mikroxizmatlarning parallel chaqiriqlari natijasida yuzaga keladigan kechikishlarning to‘g‘ri tahlili uchun juda muhimdir.

Span atributlari va hodisalari

Har bir span atributlarni o‘z ichiga olishi mumkin — meta-ma’lumotli kalit-qiymat juftliklari: so‘rov URL-i, foydalanuvchi ID-si, API versiyasi, host nomi. Atributlar tracelarni filtrlash va guruhlash uchun ishlatiladi. Atributlardan tashqari, span hodisalarni qo‘llab-quvvatlaydi — matn tavsifi bilan vaqt belgilari, masalan “kesh o‘tkazib yuborilishi” yoki “ula’lanishni qayta tiklash urinishi”.

Distributed tracing qanday ishlaydi

Distributed tracing turli jarayonlar va turli mashinalarda yaratilgan spanlarni bog‘lash muammosini hal qiladi. Mexanizm kontekst uzatishga asoslangan: A xizmatidan B xizmatiga chaqiriq paytida, chiquvchi so‘rovga joriy trace va ota-ona span identifikatori qo‘shiladi.

Kontekst uzatishning standart protokollari — W3C Trace Context (traceparent va tracestate sarlavhalari) va Zipkin B3 (X-B3-TraceId, X-B3-SpanId sarlavhalari). W3C Trace Context 2021 yilda W3C konsorsiumi tomonidan standart sifatida qabul qilingan va barcha asosiy telemetriya provayderlari tomonidan qo‘llab-quvvatlanadi.

So‘rovni qabul qilganda, B xizmati sarlavhadan trace_id ni ajratib oladi va shu trace_id bilan farzand span yaratadi. Shunday qilib, so‘rov tugagandan so‘ng, turli xizmatlardan kelgan barcha spanlar kollektor tomonida bitta trace-da birlashadi. Buning uchun har bir xizmat bir xil tracing kutubxonasi bilan instrumentatsiya qilinishi kerak.

Mikroxizmatlarda kontekst uzatish

Mobil ishlanmada kontekst uzatish nafaqat backend’ni, balki mijoz-server o‘zaro aloqasini ham qamrab oladi. Mobil ilova har bir API so‘rovining sarlavhasida trace_id yuborishi mumkin, bu esa mijoz harakatini server tomonidagi ishlov bilan bog‘lash imkonini beradi. iOS va Android uchun OpenTelemetry SDK HTTP mijozlari orqali trace kontekstining avtomatik yaratilishi va uzatilishini qo‘llab-quvvatlaydi.

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

Taqdim etilgan Kotlin interceptor’i serverga har bir HTTP so‘rovi uchun span yaratadi. Ota-ona konteksti chaqiruvchi koddan Context.current() orqali uzatiladi, bu esa mijoz tomonidagi trace’ni server tomonidagi trace bilan bog‘lash imkonini beradi.

OpenTelemetry orqali tracingni joriy qilish

OpenTelemetry — trace ma’lumotlarini yig‘ishning de-fakto standarti. Spanlarni yaratish uchun yagona API, mashhur kutubxonalarning avtomatik instrumentatsiyasi va ma’lumotlarni turli backend-larga (Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic) eksport qilishning moslashuvchan mexanizmini taqdim etadi.

Avtomatik instrumentatsiya

OpenTelemetry mashhur freymvorklar uchun spanlarning avtomatik yaratilishini qo‘llab-quvvatlaydi: Spring Boot, Ktor, Flask, Express, gRPC. Dasturchi faqat loyihaga bog‘liqlik qo‘shishi kerak, va kutubxona kiruvchi va chiquvchi so‘rovlarni mustaqil ravishda tutib oladi. Java uchun Auto-instrumentation manba kodini o‘zgartirmasdan bytecode-ni uchish vaqtida o‘zgartiruvchi javaagent-dan foydalanadi.

Mobil platformalar uchun OpenTelemetry Swift SDK va Kotlin SDK ni taqdim etadi. Ular tarmoq so‘rovlari (URLSession, OkHttp), ma’lumotlar bazasi bilan ishlash (CoreData, Room) va fon topshiriqlari uchun avtomatik span yaratadilar. Dasturchi biznes mantiqi uchun maxsus spanlar qo‘shishi mumkin.

Ma’lumotlarni eksport qilish

Yig‘ilgan spanlar OTLP (OpenTelemetry Protocol) protokoli orqali kollektorga yuboriladi. Kollektor ma’lumotlarni buferlashi, filtrlashi va bir yoki bir nechta saqlash tizimlariga yo‘naltirishi mumkin. OpenTelemetry hujjatlariga ko‘ra, span yaratilishidan uning panelda ko‘rsatilishigacha bo‘lgan odatiy kechikish gRPC eksportidan foydalanganda 2–5 soniyani tashkil qiladi.

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

Swift-dagi kod tarmoq qatlamining avtomatik instrumentatsiyasini faollashtiradi va foydalanuvchi profilini olish operatsiyasi uchun maxsus span yaratadi. user.id atributi keyinchalik tracelarni ma’lum bir foydalanuvchi bo‘yicha filtrlash imkonini beradi.

Tracelarni namuna olish strategiyalari

Yuqori yuklangan tizimlarda har bir so‘rovni tracing qilish mumkin emas — bu saqlash va tarmoqqa qabul qilib bo‘lmaydigan yuk yaratadi. Namuna olish bu muammoni hal qiladi, tracelarning faqat bir qismini saqlab. Strategiyani tanlash ma’lumotlarning to‘liqligiga va infratuzilma xarajatlariga bevosita ta’sir qiladi.

Head-based sampling

Trace’ni saqlash haqidagi qaror uni yaratish paytida — ildiz spanda qabul qilinadi. Eng sodda va keng tarqalgan yondashuv: so‘rovlarning qat’iy foizi (masalan, 5%) saqlanadi, qolganlari tashlanadi. Kamchiligi — noyob xatolarning tutilishiga kafolat yo‘q. OpenTelemetry-dagi Probability sampler 0.0 dan 1.0 gacha ehtimollikni sozlashni qo‘llab-quvvatlaydi.

Tail-based sampling

Qaror trace’ning barcha spanlari tugaguniga qadar kechiktiriladi. Analizator trace’da xatolar, vaqt oshib ketishi yoki qiziqarli atributlar mavjudligini baholaydi va shundan keyingina uni saqlaydi. Bu yondashuv kollektorda barcha spanlarni buferlashni talab qiladi, bu esa xotira sarfini oshiradi. Grafana Labs ma’lumotlariga ko‘ra, tail-based sampling noyob, ammo tanqidiy xatolarga ega tizimlarda “foydali ma’lumotlar narxi” nisbatida 40–60% samaraliroqdir.

Tracing va loglash o‘rtasidagi farq

Loglash alohida hodisalarni muhimlik darajasi bilan (info, warn, error) qayd etadi, lekin ularni bitta so‘rov kontekstida bog‘lamaydi. Tracing, aksincha, bitta uchdan-uchga so‘rovga tegishli bo‘lgan tuzilgan operatsiyalar daraxtini yaratadi. Amalda, bu ikki yondashuv bir-birini istisno qilmaydi, balki to‘ldiradi.

Loglar ma’lum bir xatoning batafsil tahlili uchun samarali: dasturchi aniq xabarni, chaqiruv stekini, o‘zgaruvchilar qiymatlarini ko‘radi. Tracing “so‘rov nima uchun 5 soniya davom etadi” degan savolga javob beradi — qaysi mikroxizmat yoki chaqiriq eng ko‘p vaqt olganini ko‘rsatadi. Honeycomb (2024) ma’lumotlariga ko‘ra, tracing bilan birga loglashdan foydalanadigan jamoalar hodisalarning asosiy sababini 2,3 marta tezroq topadilar.

Zamonaviy yondashuv — observability — tracing, metrikalar va loglarni yagona tizimda birlashtiradi. OpenTelemetry bu uch signal o‘rtasidagi korrelyatsiyani qo‘llab-quvvatlaydi: har bir span bog‘liq loglarga havolalarni o‘z ichiga olishi mumkin, metrikalar esa aniq tracelarga o‘tish uchun trace_id bilan belgilanishi mumkin.