Trace — taqsimlangan tizimda bitta request yoki mantiqiy operatsiyaning xizmatlar va komponentlar bo‘ylab bajarilish yo‘lini ifodalovchi telemetry yozuvidir. Trace bir-biri bilan parent-child yoki link aloqasida bo‘lgan spanlardan tuziladi. U latency qayerda sarflangani, qaysi dependency xato bergani va parallel ishlar qanday kechganini ko‘rsatadi.
Trace tuzilishi
Har trace odatda 128-bit trace ID bilan aniqlanadi. Root span operatsiyaning boshlanishini, child spanlar HTTP chaqiruvi, database query, queue publish yoki ichki hisobni ifodalaydi. Start time va duration vaqt chizig‘ini hosil qiladi.
Span attribute service, route, status code, database system va boshqa past cardinality kontekstni beradi. Event span ichidagi muhim vaqt nuqtasi, masalan exception yoki retryni qayd etadi. Status operatsiya muvaffaqiyatini umumiy tarzda bildiradi, lekin domen natijasi alohida atribut talab qilishi mumkin.
Distributed propagation
Trace bir processdan boshqasiga o‘tishi uchun trace context request header yoki message propertyga inject qilinadi. Receiver uni extract qilib parent context asosida yangi span yaratadi. W3C traceparent umumiy format beradi; vendor tracestate qo‘shimcha ma’lumot saqlashi mumkin.
Context uzatilmasa yangi root trace paydo bo‘lib, operatsiya bo‘linadi. Noto‘g‘ri global context parallel requestlarni bitta tracega aralashtiradi. Async runtimega mos propagation mexanizmi ishlatiladi.
Asinxron va batch ishlar
Queue producer spanidan consumer spanigacha vaqt messaging delayni o‘z ichiga olishi mumkin. Consumer ishlovi producer request tugagandan keyin boshlansa parent-child har doim eng to‘g‘ri model emas; span link causal aloqani bildirishi mumkin. Bitta batch bir nechta message contextini link orqali bog‘laydi.
Uzoq workflow bir necha soat yoki kun davom etsa bitta juda uzun trace storage va query uchun noqulay. Har bosqich mustaqil trace bo‘lib, business correlation ID bilan bog‘lanishi mumkin. Scope tizim dizayniga qarab tanlanadi.
Sampling
Har request trace qilinsa yuqori trafikda katta hajm hosil bo‘ladi. Head sampling trace boshida qaror qiladi; tail sampling barcha spanlar collector ga kelgach error, latency yoki attribute bo‘yicha tanlaydi. Sampling qilinmagan trace ID logda qolishi mumkin, ammo tracing backendda ma’lumot bo‘lmaydi.
Sampling rate performance statistic uchun og‘irlik bilan talqin qilinadi. Faqat xatolarni saqlash odatiy successful latency taqsimotini ko‘rsatmaydi. Muhim tenant yoki route uchun alohida policy qo‘llanishi mumkin.
Tahlil va cheklovlar
Critical path parallel spanlar ichida umumiy latencyga ta’sir qilgan ketma-ket yo‘lni ko‘rsatadi. Eng uzun span har doim bottleneck emas; u boshqa ish bilan parallel bo‘lishi mumkin. Missing instrumentation bo‘sh vaqt sifatida ko‘rinadi.
Trace observability dalili, audit log emas. Sampling va collector failure sabab to‘liq bo‘lmasligi mumkin. Attribute va eventga token, SQL literal yoki shaxsiy data yozilmaydi. Tenant access, retention va redaction tracing backendda ham qo‘llanadi.
Service graph
Trace spanlaridan service dependency graph hosil qilish mumkin. Client va server span orasidagi relationship service edge, duration va error statistikasi uchun ishlatiladi. Instrumentation nomlari noto‘g‘ri bo‘lsa bir xizmat bir nechta nodega bo‘linadi yoki turli xizmatlar birlashadi.
Trace to‘liq bo‘lmasa graph trafikning faqat sampled qismini ko‘rsatadi. Asinxron message linklari oddiy parent-child graphga sig‘masligi mumkin. Graph topology inventarining mutlaq manbasi emas, kuzatilgan operatsiyalar namunasi hisoblanadi.
Bog‘liq tushunchalar
Distributed tracing, Span, Trace ID, Trace context, Sampling, OpenTelemetry, Critical path