OpenTelemetry nima va taqsimlangan trassirovka qanday ishlaydi

Qisqa javob

OpenTelemetry (OTel) — telemetriya yig‘ish uchun ochiq standart hamda SDK va vositalar to‘plami: trace, metrika va loglar. U biror vendorga bog‘lanmagan: kodni bir marta instrumentatsiya qilasiz va ma’lumotlarni OTLP protokolini tushunadigan istalgan backendga yuborasiz.

Taqsimlangan trassirovka bitta savolga javob beradi: muayyan so‘rov frontend, API, navbatlar, ma’lumotlar bazalari va boshqa servislar orqali o‘tayotganda u bilan nima bo‘ldi. Har bir so‘rov trace ID oladi, har bir qadam o‘z vaqtini yozib boradi, backend esa qadamlarni yagona vaqt shkalasiga yig‘adi.

Trace va spanlar

• Trace — bitta so‘rovning to‘liq tarixi, kirish nuqtasidan bazaga oxirgi murojaatgacha.
• Span — trace ichidagi bitta operatsiya: HTTP-handler, SQL so‘rov, tashqi API chaqiruvi. Spanning nomi, boshlanish va tugash vaqti, statusi va atributlari bor (masalan, http.route yoki db.system).
• Spanlar daraxt hosil qiladi: ildiz span — kiruvchi so‘rov, bola spanlar — u ishga tushirgan ishlar.

Daraxtga qarab qaysi qadam eng ko‘p vaqt olganini yoki xato qayerda yuz berganini darhol ko‘rasiz, beshta turli servis loglarini solishtirib o‘tirmaysiz.

Kontekst qanday uzatiladi

Turli servislardagi spanlar bitta trace’ga tushishi uchun trace ID so‘rov bilan birga harakatlanishi kerak. Bu context propagation deb ataladi.

1. A servis trace’ni boshlaydi va span yaratadi.
2. B servisni chaqirishda SDK trace ID va joriy span ID bilan sarlavha qo‘shadi. Standart format — W3C Trace Context (traceparent sarlavhasi).
3. B servis sarlavhani o‘qiydi va o‘z spanlarini A spanining bolalari sifatida yaratadi.
4. Xabarlar navbatida ham xuddi shunday: kontekst xabar sarlavhalariga joylanadi.

Agar zanjirdagi bitta servis ham sarlavhalarni uzatmasa, trace bo‘laklarga bo‘linib ketadi. Bu «to‘liq bo‘lmagan» trace’larning eng ko‘p uchraydigan sababi.

OpenTelemetry Collector

Collector — ilovalar va backend o‘rtasida turadigan alohida jarayon. Uning konveyeri uch qismdan iborat:

• receivers ma’lumotlarni qabul qiladi (OTLP, Jaeger, Prometheus va boshqalar);
• processors ma’lumotlarni guruhlaydi, filtrlaydi, boyitadi va sempling qo‘llaydi;
• exporters ma’lumotlarni bitta yoki bir nechta backendga yuboradi.

Minimal konfiguratsiya quyidagicha:

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
exporters:
  otlp:
    endpoint: tempo:4317
    tls:
      insecure: true
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Ilovadan to‘g‘ridan-to‘g‘ri eksport qilish mumkin bo‘lsa, Collector nima uchun kerak? Backendni servislarni qayta deploy qilmasdan almashtirish mumkin, maxfiy kalitlar ilova kodiga tushmaydi, sempling va ma’lumot hajmi bir joyda boshqariladi.

Amalda nimadan boshlash kerak

• Avtomatik instrumentatsiyadan boshlang: ko‘p tillar uchun HTTP-serverlar, klientlar va DB drayverlari uchun kodni o‘zgartirmasdan span yaratadigan agent va kutubxonalar bor.
• Har bir servisga tushunarli service.name bering, aks holda trace’larni o‘qish qiyin bo‘ladi.
• Qo‘lda spanlarni faqat muhim biznes-operatsiyalar atrofida qo‘shing.
• Semplingni sozlang: yuklangan tizimning har bir trace’ini saqlash qimmat. Head sampling trace’larning qat’iy ulushini saqlaydi, Collector’dagi tail sampling esa xatoli yoki yuqori kechikishli barcha trace’larni saqlab qolishi mumkin.
• Log va trace’larni bog‘lang: har bir log qatoriga trace ID yozing.

Backendlarni taqqoslash

OTel vendorga bog‘lanmaganligi sababli tanlov yakuniy emas: Jaeger yoki Tempo bilan boshlab, keyinroq Collector’dagi exporter’ni almashtirish kifoya.

Ko‘p uchraydigan xatolar

• Sarlavhalar proksi, shlyuz yoki navbat orqali uzatilmaydi va trace’lar uziladi.
• Foydasiz spanlar juda ko‘p, masalan har bir mayda funksiyaga span.
• Span atributlarida shaxsiy ma’lumotlar: tokenlar, telefon raqamlari, so‘rov tanalari.
• Sempling yo‘q, natijada ombor yoki SaaS uchun hisob kutilmagan bo‘lib chiqadi.