API analitikasi va unumdorlik metrikasi

1) Nima uchun bu zarur?

• SLO va SLA bajarilganligini isbotlash,
• o’tkazish qobiliyatini va so’rovlar iqtisodiyotini boshqarish,
• tanazzullarni tezda mahalliylashtirish (p99-dumlar, 5xx portlashlar),
• biznesga ta’sir ko’rsatish bo’yicha optimallashtirishni ustuvor belgilash.

Maqsad: kuzatishning yagona modeli bo’lib, unda har bir so’rov perimetrdan umumiy identifikatorlar va kelishilgan SLI bilan DBgacha kuzatiladi.

2) Metriklarning taksonomiyasi

Texnik: RPS, latentlik (p50/p95/p99), error rate (4xx/5xx), saturation (CPU, memory, file-desc), queue time.
Mahsulotlar: muvaffaqiyatli operatsiyalar/min, qadam konvertatsiyasi (200/total), rate-limited ulushi (429), retralar, foydalanuvchi segmentlari.
Qiymati: cost/request (CPU-ms + egress + BD-so’rovlar), fich/endpint qiymati, $/tenant, $/1k qo’ng’iroqlar.

3) «Oltin signallar»: RED va USE

• Rate - so’rovlar/sek (endpoint/tenant/reja bo’yicha).
• Errors - 4xx/5xx/429 ulush va absolyutlar.
• Duration - p50/p95/p99 end-to-end va bosqichlar bo’yicha (ingress → app → DB → uchinchi tomon).

• Utilization - CPU/IO/kanalni yuklash.
• Saturation - navbatlar (run-queue, backlog, DB wait).
• Errors - haydovchi/taymaut xatolari.

4) Bazaviy ta’riflar va formulalar

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Success SLI:’2xx/( all − 429_shadow)’(«soyali» blokirovkalar bundan mustasno).
Apdex: `(|T≤T| + 0. 5· | T ≤ 4T | )/all’, bunda’T’- maqsadli «yaxshi» chegara.
Tail amplification:’p99 _ total − max (p99_stage_i)’- navbat/kompozitsiya hissasi.
Error budget (oy) 99 da. 9%:’budjet = 0. _ Davr uchun% 1’.

Latency gistogrammalarining tavsiya etilgan pertsentil binlari:’[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO va burn-rate bo’yicha alerting

• Foydalanish imkoniyati: 99 ≥. 9 %/30 kun.
• p95 latentlik’GET/wallet/balance’<150 ms;’POST/payments’<400 ms.
• Xatolar’5xx’<0. 2%.’429’(qattiq) <1% umumiy trafikdan.

• 1 soat uchun 2% budjet yoki 6 soat uchun 5% → page muhandis.
• kuniga 10% → RCA ustuvorligi.

6) Metriklar to’plami (buni yig’ish shart)

• `http_requests_total{route,method,status,tenant,plan}`
• ’http _ request _ duration _ seconds _ bucket {route,...}’ (gistogramma)
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• Tana oʻlchamlari:’request _ bytes’,’response _ bytes ’

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• ’cache _ ops _ total {op}’, hit-rate kesh tashqi qoʻngʻiroqlar:’outbound _ calls _ total {provider, op}’, latency/xato/taymaut navbatlar/pullar: uzunliklar/kechikishlar, aktiv vorkerlar resurs USE: CPU, RSS, FD, GC pauzalari

Biznes-yorliqlar:’tenant _ id’,’region’,’kyc _ level’,’plan’,’feature _ flag’.

7) Trastirovka va korrelyatsiya (OpenTelemetry)

Barcha xoplarda W3C Trace-Context (’traceparent’,’tracestate’).
Span-lar bosqichlari bo’yicha: ingress → authZ → app handler → DB/Redis → PSP/tashqi.
Attributes/yorliqlar:’http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Exemplars: latency/error grafiklaridagi nuqtalarni aniq trace-id bilan bogʻlang.

• «oddiy» yo’llar uchun head-based 1-10%,
• tail-based (biz sekin/noto’g "ri olamiz),
• choʻqqilar va hodisalar uchun adaptive.
• Baggage:’tenant ’/’ risk’har bir hodisani belgilamasdan kesish uchun.

8) Logi: tuzilmasi va maxfiyligi

Tuzilgan JSON; ’ts’,’trace _ id’,’span _ id’,’route’,’status’,’latency _ ms’,’tenant’,’user _ id _ hash’majburiy maydonlari.
PII siyosati: PAN/PII ni yashiring; sirlarni/tokenlarni taqiqlang.
Sampling log: 4xx/5xx/429 va «uzun» so’rovlar uchun yuqori.

9) Dashbordlar xaritasi (minimal to’plam)

1. Exec-Summary: RPS, Availability, Error-rate, p95/p99 latency, 429 ulush, burn-rate budjeti.
2. Per-Route: RPS/xatolar/dumlar bo’yicha top-endointlar; versiyalarni taqqoslash (kanareycha).
3. Per-Tenant/Plan: yuk/qiymat/xato bo’yicha etakchi.
4. Dependency Health: DB, cache, PSP/tashqi - latency, xato, saturation.
5. Capacity: CPU/RAM/FD, navbatlar, connection pool, GC, konteyner limitlari.
6. Security/Abuse: 401/403, 429/siyosati, geo/ASN kesmalari, retray portlashlari.

10) Alertlar (chegara va trend)

’error _ rate {route}’> 2% (5 daqiqa) va RPS> N → pager.
’p99 _ latency {critical}’> maqsadli chegara (10 daqiqa).
budjet bo’yicha’burn _ rate’(§ 5 ga qarang).
DB’timeouts ’/’ deadlocks’yoki’queue _ time’> X ms.
Tashqi provayderlar:’outbound _ 5xx _ rate {provider}’> 1% + SLOga bogʻliq.

11) Sig’imli rejalashtirish va unumdorlik

Littl qonuni:’L = λ· W’(navbatning o’rtacha uzunligi = trafik × o’rtacha vaqt).
Maqsadli p95’ingress + app + DB + external + queue’.
Concurrency budget: bir vaqtning o’zida eng ko’p write-operatsiyalarni qayd etamiz.
Budget-metrika: «So’rov uchun ms CPU»; eng yuqori cho’qqisiga 30-50% zaxirani saqlaymiz.
rate-limit bilan o’zaro ta’sir: kvota «shifti» so’rovlar ulushini va yashirin ta’sirini o’lchang.

12) Yuklama va sintetik tekshiruvlar

Turlari: bazaviy yuk, 10 × burstlar, «bosqichlar», uzoq muddatli platolar, stress/chaos (nodlarni o’ldirish, tarmoqni kechiktirish), tanqidiy mijoz stsenariylari bo’yicha sintetika.
Profillash: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), sekin kodlar.
Regressiyalarni nazorat qilish: r95/r99/relizdan oldin/keyin xatolarni solishtirish (kanareya).

13) Qiymat (Cost-Observability)

Xarajatlar metrikasi:’cpu _ ms’,’egress _ bytes’,’db _ calls’,’$ per 1k requests’.
Endpoint/tenant/fichu uchun allokatsiya: orkestratordan billing teglari + yuk metrikasi → API yunit-iqtisodiyoti bo’yicha hisobot.
Optimallashtirish algoritmi:’traffic × cost × (p95 − maqsad)’asari boʻyicha TOP-endpointlarni tanlaymiz.

14) Tahliliy va «adolat» per-tenanti

Barcha asosiy metriklar - «tenant _ id/plan» yorlig’i bilan.
«Og’ir» mijozlarning p99 qoldiqlaridagi ulushi; retraylarning alohida limitlari/kvotalari va budjetlari.
Adolatli SHayring: ortiqcha yuklashda «baland ovozda» ijarachilar ulushini kamaytiramiz.

15) iGaming/Moliya xususiyatlari

’kyc _ level’,’risk _ tier’,’payment _ method’bo’yicha kesmalar.
«Pul» yo’llari uchun SLI (’POST/deposits’,’POST/withdrawals’): quyidagi maqsadli p95, alohida xato budjetlari.
Time-to-Wallet metrikasi (TTW), antifrod bilan avtobloklar ulushi, to’lov konvertatsiyasi.
Audit: moliyaviy harakatlar va antifrod qarorlari uchun o’zgarmas jurnallar.

16) Instrumentatsiya: amalga oshirish amaliyotlari

• `api_http_requests_total` (counter)
• `api_http_request_duration_seconds` (histogram)
• `api_outbound_requests_total`, `api_db_query_duration_seconds`
• `api_rate_limited_total`, `api_retry_total{reason}`

Лейблы: `route`, `method`, `status_class`, `tenant`, `region`, `version`, `canary`, `provider`, `db_table`.
Kardinallik: erkin qiymatlardan qoching (user_id), «baketalar »/xesh.
Exemplars: p95/p99 gistogrammalariga ulaning → trace.

17) Antipatternlar

Pertsentillar o’rniga o’rtacha; status-klasslarga bo’linmaslik.
Kelishilmagan’route ’/’ path’(dinamik ID yorliqlarga «tikilgan»).
Yuqori kardinallikka ega leybllar (raw user_id, IP).
Tashqi provayderlarni alohida hisobga olishning yo’qligi (PSP/3rd-party).
Alertlar «shovqin» bo’yicha (bitta va bitta ostona).
p99 (haqiqiy degradatsiyani yashiradi).

18) Prod-tayyorgarlikning nazorat ro’yxati

• SLI/SLO va error-budget aniqlangan, biznes bilan kelishilgan.
• Latency yagona gistogrammalari va status-klasslari; dashbordlarda p95/p99.
• To’liq tras (OTel), loglar/metriklar/treyslarning korrelyatsiyasi.
• Burn-rate (ikki oynali) alertlari, p99 va error-rate bo’yicha ostonalar.
• Per-tenant/per-reja kesimlari va qiymat bo’yicha hisobotlar.
• Dashbordlar: Exec, Per-Route, Dependencies, Capacity, Abuse.
• Yuklash stsenariylari (burst/plato/stress), profillash.
• Jitter bilan retraj siyosati; retraylarning RPSga ta’sirini hisobga olish.
• Hamkorlar va ommaviy mijozlar uchun SLA/SLO hujjatlari.
• Ro’yxatga olish/yashirish, PII himoyasi.

19) TL; DR

SLI/SLO va error-budget atrofida kuzatish imkoniyatini yarating, RED/USE o’lchang, p95/p99 va «queue time» latency gistogrammalarini yig’ing, perimetrdan DBgacha yagona trace-id tarqating, tail/adaptive-sampling dan foydalaning, per-tenant saqlang/qiymat kesimlari va ikki oynali burn-rate-alerting. Sig’imni navbat qonunlari va biznes metrikaga ta’siri bo’yicha rejalashtiring; antipatternlar - pertsentillar o’rniga o’rtacha, yuqori kardinallik va hisobga olinmagan tashqi qaramliklar.