Observability и trace sampling

1) Observability nima uchun

• Metrika (agregatlar, tez reaksiyaga kirishadilar);
• Logi (detallar va forenzika);
• Treyslar (uzluksiz sababiy-oqibatli aloqalar);
• Profillar (CPU/heap/lock contention prod rejimida).

Kalit: signallar orasidagi korrelyatsiya + telemetriya iqtisodiyoti (samplash, retensiya, siqish).

2) Signallar xaritasi va prinsiplari

2. 1 RED/USE

RED (API uchun): Rate (RPS), Errors (% 5xx/4xx muhim), Duration (p50/p95/p99).
USE (resurslar uchun): Utilization, Saturation, Errors (NIC, CPU, disk, navbatlar).

2. 2 Mahsulot invariantlari

SLOni aniqlang (masalan, "p95 latentlik ’/v1/payments’≤ 300 ms, xato byudjet 0. 30 kunda 5%"). Alertlar faqat SLO buzilganda yoki u yonganda «qichqirishlari» kerak.

2. 3 Kontekst

W3C Trace Context (’traceparent’,’tracestate’) va/biznes atributlarini xavfsiz uzatish uchun baggage (masalan,’tenant’,’region’, PIIsiz) ni kiriting.

3) Kuzatish arxitekturasi

SDK/avtoinstrumentatsiya: OpenTelemetry (OTel) xizmatlarida (HTTP/gRPC/DB/mijozlar).
OTel Collector shina sifatida: qabul → boyitish → semplash → eksport (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• Metrikasi: Prometheus/Mimir/VictoriaMetrics;
• Treyslar: Tempo/Jaeger/Zipkin;
• Logi: Loki/ELK/Vector → S3 + arzon saqlash;
• Profillar: Pyroscope/Parca.
• Korrelyatsiya: servislar grafalari, exemplars, p99 grafikdan aniq treysga o’tish.

4) Treysingni samplash: strategiyalar

4. 1 Head-based sampling (kirish joyida, natijani bilishdan oldin)

Oddiy va arzon sotish (SDK/ingress).
Kamchiliklar: kamdan-kam xatolar/sekin so’rovlarni o’tkazib yuborishi mumkin.

Qachon: yuqori RPS, qat’iy byudjetlar, bashorat qilinadigan ulush talab qilinadi (masalan, 1-5%).

4. 2 Tail-based sampling (natijasini bilgan holda chiqish)

Qaror span tugagandan so’ng Collector’da qabul qilinadi.
Siz anomaliyalarni tanlashingiz mumkin: xatolar, p99, aniq routlar/tenantlar.
Salbiy tomonlari: buferlash, qiyinroq va qimmatroq.

Qachon: o’rtacha narxda «muhim» treyslar kerak.

4. 3 Kombinatsiyalangan model

Global head 1-5%, plyus tail qoidalari: «doimo xatolarni/slow-spanlarni saqlash», «50% canary-trafikni sempllash», «hodisa yuz berganda to’lov yo’llarining barcha treyslarini saqlash».

5) Dinamik samplash va telemetriya budjeti

Budget-aware: N treys/min ≤ hajmini ushlab qolish; oshganda - chegaralarni ko’tarish (masalan, faqat p99 tanlash). 5+, error-only).
Rules by route/tenant: muhim endpointlar/tenantlar - katta ulush bilan.
Moslashuvchan oynalar: chaqnashlar → xatolar/sekinliklar ulushini vaqtincha oshirish.
Kardinallikni kamaytirish: user-agent, IP/ASN, squash stack traces, sirlarni yashiring.

6) Konfigi (referensiyalar)

6. 1 OpenTelemetry Collector - tail-sampling (yaml-fraqment)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6. 2 Prometheus - exemplars (parcha)

Ilovada gistogrammalarni yozishda’trace _ id’bilan exemplars qoʻshing. Grafanada «igna» lar treysga olib boradi.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6. 3 Loki - loglar qiymatining pasayishi

Faqat barqaror belgilar (’service’,’env’,’region’,’route _ class’).
Yuqori kardinallik (request_id, user_id) - payload, lekin redaction.
«Muvaffaqiyatli» info-loglarni sample qiling, barcha xatolar/ogohlantirishlarni saqlang.

6. 4 Jaeger/Tempo - retenshn va indeks

Xom treyslarni 3-7 kun, agregatlarni/simmetriyalarni uzoqroq saqlang.
Parquet/blocksni arzon (S3-mos) saqlash joyiga kiriting, indekslar ixcham.

7) Treysingni modellashtirish

7. 1 Nomlash va atributlar

`service. name`, `service. version`, `deployment. environment`.
`http. method`, `http. route`, `http. target`, `http. status_code`, `net. peer. name`.
PIIsiz biznes atributlar:’tenant’,’region’,’payment _ provider’,’game _ id’.

7. 2 Voqealar va aloqalar

Span events: muhim nuqtalar (DB tranzaksiyasining boshlanishi, retray, circuit open, cache miss).
Links: aloqa soʻrovi → vebxuk/hodisa; EDA va outbox/inbox uchun foydalidir.

7. 3 nusxa (exemplars)

latency/size gistogrammalariga’trace _ id’:’metrikadan → treysga’bir marta bosish orqali misollar qoʻshing.

8) Metrika: qanday va qanday

8. 1 Texnik

Yo’nalishlar/tenantlar/provayderlar bo’yicha RED (PSP, KYC).
Пулы: `db_connections_in_use`, `http_client_in_flight`, `queue_depth`.
Barqarorlashtirish: retries, timeouts, circuit open/half-open, rate-limit hits.
Go/Java/Python runtime: GC pauzalari, heap, safepoints, GIL kechikishlari.

8. 2 Biznes-metriklar

Ro’yxatdan o’tish/loginlar/depozitlar/xulosalar, konvertatsiya, 3DS/KYC muvaffaqiyatsizliklari, chargeback-ratio.
Muhim fichlar: time-to-wallet, success-rate payout.

8. 3. Kardinallik va saqlash

Aniq buckets bilan gistogrammalar (masalan,’[50,100,200,300,500,1000,2000] ms’).
Yuqori kardinallik belgilaridan qoching (raw user_id, request_id) - loglar/treyslarga olib chiqish.

9) Logi: standartlar va korrelyatsiya

Formati: JSON + kerakli kalitlar (’timestamp’,’level’,’message’,’trace _ id’,’span _ id’,’service’,’env’).
Tahrirlash: PAN, tokenlar, PIIlarni yashiring.
Sampling:’error/warn’uchun 100%,’shovqinli’yo’llarda’info’uchun 5-20%.
Treyslarni’trace _ id’orqali bogʻlash. Log-satrlar → «pivot» treysga va aksincha.

10) Proda profiling

CPU/heap/alloc/locks uchun continuous profiling (Pyroscope/Parca) ni kiriting.
p99 cho’qqilarini issiq stakanlar bilan bog’lang; 7-14 kun saqlang.

11) SLO/noto’g "ri budjet bo’yicha alerting

SLO-alertlar: "noto’g" ri budjet X %/soatdan tezroq sarflanadi "(prognoz qiluvchi alertlar).
Alomatlar, sababi emas: CPU emas, balki mijoz darajasiga (RUM/edge yoki per-rout) alertite.
Multi-window, multi-burn rate: 1 soat uchun 2% va 6 soat uchun 5% - ikkita shart.
Rejali degradatsiyalarda sukunat: fich-bayroqlar/kanareykalarda ostonalarning siljishi.

12) Qiymat va retenshn

Hajmlar uchun kvotalar: treyslar ≤ N TB/oy, logi - issiq 3-7 kun, sovuq S3 - 30-90 kun, metrika - downsampling (1 min → 5 min → 1 soat).
Tail-rules noto’g’ri/sekin bo’lgan × 10- × 100 hajmini kamaytiradi.
Qiymati eng kam bo’lgan signallar - metrika; eng katta qiymatga ega bo’lgan - "to’g" ri "treyslar va profillar.

13) Antipatternlar

«100% treys doimo» → qiymat portlashi, shovqin va tormoz.
Tugmalar erkin formatda kalitsiz/yashirinmagan holda.
Cheksiz yorliqli metriklar (user_id/ip/full UA).
’traceparent ’/’ baggage’ - korelatsiya mumkin emas.
CPU/heap’dagi alertlar SLO - chat o’rniga foydasiz «yonadi».
Xato/slow ustuvorligisiz «1%» bilan samplay qilish - qimmatli keyslarni yoʻqotasiz.

14) Dashbordlar (skeletlar) namunalari

API Overview: RPS, sinflar boʻyicha error-rate, latency p95/p99 (exemplars klibable), top-routlar.
Release/Canary: eski/yangi versiya, outlier-rate, open-circuits, retries metrikalarini taqqoslash.
PSP/KYC: provayderlar bo’yicha success-rate, latency va rad etish, payout xatolari bilan bog’lanish.
Infra: resurslar boʻyicha USE, navbatlar saturatsiyasi, network drops.

15) iGaming/Moliya xususiyatlari

Tanqidiy yo’llar (depozitlar/xulosalar): 100% treysing faqat hodisalar yoki cheklangan derazalarda; shtat rejimida - tail «hammasi xato/uzoq yashirin».
Mintaqa/tenant: baggage’tenant’,’jurisdiction’,’brand’qoʻshing; yurisdiksiya bo’yicha SLO quring.
Antifrod/bot-filtr: Risk API (allow/deny/challenge), challenge-pass-rate, velocity-hits metrikalari va treyslari.
Audit/komplayens: eng kam zarur narsalarni PIIsiz saqlash; o’zgartirilmaydigan jurnallar - alohida konturda.

16) Prod-tayyorlik chek-varaqasi

• Uzluksiz targ’ibot (’traceparent’,’baggage’), loglar/metriklar/treyslarning korrelyatsiyasi.
• tail-sampling (errors/slow/muhim routlar) + probabilistic default bilan OTel Collector.
• RED/USE metrikalari, aniq buckets, exemplars → treysga o’tish.
• SLO va noto’g "ri byudjet bo’yicha alerting (ikkita vaqt shkalasi).
• Retensiya reglamentlari va telemetriya budjeti; downsampling metrik; loglar uchun cold storage.
• Standartlashtirilgan JSON-log, redaction PII/sirlar.
• Proda profiling kiritilgan; hodisaga doir «issiq» steklar dashbordlari.
• Kanar dashbordlari va versiyalarni taqqoslash; «ko’r zonalarsiz» chiqarish.
• Runbook: hodisada vaqtincha samplash ulushini oshirish.
• Atributlar/belgilar neymingi hujjatlari va high-cardinality taqiqlanadi.

17) TL; DR

RED/USE → exemplars → treyslar → loglar/profillar metrikasi bilan bog’laning. Qiymatni kichik head% + tail qoidalari (xatolar, sekin, muhim yo’nalishlar/tenantlar) yordamida boshqaring. Alertlar - SLO va xatolar byudjeti boʻyicha. Retensiya va kardinallikni nazorat ostida ushlab turing, OTel Collector’dan «markaziy asab tizimi» sifatida foydalaning. To’lov/yurisdiksiya yo’llari uchun - ustuvor telemetriya va qat’iy ma’lumotlar gigiyenasi.