API analitikası və performans metrikası

1) Niyə lazımdır

• SLO və SLA-nın icrasını sübut etmək,
• tələb qabiliyyətini və iqtisadiyyatını idarə etmək,
• sürətlə deqradasiyanı lokallaşdırın (p99-quyruqlar, 5xx sıçrayışlar),
• biznesə təsir üçün optimallaşdırmaya üstünlük verin.

Məqsəd: hər bir sorğunun ümumi identifikatorları və razılaşdırılmış SLI ilə perimetrdən DB-yə qədər izlənildiyi vahid müşahidə modeli.

2) Metrik taksonomiya

Texniki: RPS, gecikmə (p50/p95/p99), error rate (4xx/5xx), saturation (CPU, memory, file-desc), queue time.
Məhsullar: uğurlu əməliyyatlar/dəq, addım çevirmə (200/total), rate-limited payı (429), retralar, xüsusi seqmentlər.
Qiymət: cost/request (CPU-ms + egress + DB-sorğular), fich/end point dəyəri, $/tenant, $/1k zənglər.

3) «Qızıl siqnallar»: RED və USE

• Rate - sorğular/san (end point/tenant/plan üzrə).
• Errors - 4xx/5xx/429 pay və mütləq.
• Duration - p50/p95/p99 end-to-end və mərhələləri (ingress → app → DB → üçüncü tərəf).

• Utilization - CPU/IO/kanal yükləmə.
• Saturation - növbələr (run-queue, backlog, DB wait).
• Errors - sürücülər/vaxt səhvləri.

4) Əsas təriflər və düsturlar

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Success SLI: '2xx/( all − 429_shadow)' («kölgə» blokları istisna olmaqla).
Apdex: `(|T≤T| + 0. 5· | T ≤ 4T | )/all ', harada' T 'hədəf «yaxşı» eşik.
Tail amplification: 'p99 _ total − max (p99_stage_i)' - növbə/kompozisiyanın töhfəsi.
Error budget (ay) 99. 9%: 'büdcə = 0. 1% zaman _ period '.

Tövsiyə olunan latency histoqramları: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO və burn-rate ilə alertinq

• Mövcudluq: ≥ 99. 9 %/30 gün.
• p95 latentlik 'GET/wallet/balance' <150 ms; 'POST/payments' <400 ms.
• Xətalar '5xx' <0. 2%. '429' (bərk) <1% ümumi trafik.

• 2% büdcə 1 saat və ya 5% 6 saat → page mühəndis üçün.
• 10 %/gün → RCA prioritetləşdirilməsi.

6) Metrik dəsti (yığmaq lazımdır)

• `http_requests_total{route,method,status,tenant,plan}`
• 'http _ request _ duration _ seconds _ bucket {route,...}' (histoqram)
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• Bədən ölçüləri: 'request _ bytes', 'response _ bytes'

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• 'cache _ ops _ total {op}', xarici çağırışlar hit-rate cache: 'outbound _ calls _ total {provider, op}', latency/səhvlər/növbə vaxtı/hovuzlar: uzunluqlar/gecikmələr, aktiv workers resurs USE: CPU, RSS, FD, GC fasilələri

Biznes etiketləri: 'tenant _ id', 'region', 'kyc _ level', 'plan', 'feature _ flag'.

7) İzləmə və korrelyasiya (OpenTelemetry)

W3C Trace-Context ('traceparent', 'tracestate') bütün hoplarda.
Span-lar mərhələlər üzrə: ingress → authZ → app handler → DB/Redis → PSP/xarici.
Attributes/etiketlər: 'http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Exemplars: latency/error qrafiklərindəki nöqtələri xüsusi trace-id ilə əlaqələndirin.

• «Adi» yollar üçün head-based 1-10%,
• quyruqlar üçün tail-based (yavaş/səhv götürün),
• zirvələri və hadisələr üçün adaptive.
• Baggage: Hər bir hadisəni işarə etmədən kəsiklər üçün 'tenant '/' risk' köçürülməsi.

8) Log: struktur və gizlilik

Strukturlaşdırılmış JSON; Məcburi sahələr: 'ts', 'trace _ id', 'span _ id', 'route', 'status', 'latency _ ms', 'tenant', 'user _ id _ hash'.
PII siyasəti: PAN/PII maskası; sirləri/tokenləri qadağan edin.
Sampling log: 4xx/5xx/429 və «uzun» sorğular üçün yüksək.

9) Dashboard xəritəsi (minimum dəsti)

1. Exec-Summary: RPS, Availability, Error-rate, p95/p99 latency, 429 pay, burn-rate büdcə.
2. Per-Route: RPS/səhvlər/quyruqlar üzrə üst endointlər; versiyaların müqayisəsi (kanarya).
3. Per-Tenant/Plan: yük/dəyər/səhvlər üzrə liderlər.
4. Dependency Health: DB, cache, PSP/xarici - latency, səhvlər, saturation.
5. Capacity: CPU/RAM/FD, növbələr, connection pool, GC, konteyner limitləri.
6. Security/Abuse: 401/403, 429/siyasətlər, geo/ASN dilimləri, retras sıçrama.

10) Alertlər (eşik və trend)

'error _ rate {route}'> 2% (5 dəqiqə) və RPS> N → pager.
'p99 _ latency {critical}'> hədəf həddi (10 dəqiqə).
'burn _ rate' büdcə üzrə (bax § 5).
DB 'timeouts '/' deadlocks' və ya artım 'queue _ time'> X ms.
Xarici provayderlər: 'outbound _ 5xx _ rate {provider}'> 1% + SLO asılı.

11) Tutumlu planlaşdırma və performans

Little Law: 'L = λ· W' (orta növbə uzunluğu = trafik × orta vaxt).
Hədəf p95 yerləşdirilir: 'ingress + app + DB + external + queue'.
Concurrency budget: eyni anda maksimum write əməliyyatları qeyd.
Budget-metrika: «Sorğu üçün ms CPU»; pik 30-50% ehtiyat saxlamaq.
Rate-limit ilə qarşılıqlı əlaqə: kvotaların «tavan» sorğularının payını və gecikmənin təsirini ölçün.

12) Yük və sintetik yoxlamalar

Növlər: əsas yük, × 10, «addımlar», uzunmüddətli platolar, stress/chaos (nod öldürmə, şəbəkə gecikmələri), kritik müştəri ssenariləri üzrə sintetika.
Profil: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), yavaş kodlar.
Regres nəzarəti: p95/p99/buraxılışdan əvvəl/sonra səhvlərin müqayisəsi (kanarya).

13) Qiymət (Cost-Observability)

Xərclərin ölçüsü: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
End point/tenant/fichu allokasiyası: orkestratordan billing etiketləri + yükləmə metrikası → API vahid iqtisadiyyatı hesabatı.
Optimallaşdırma alqoritmi: 'traffic × cost × (p95 − hədəf)' məhsulu ilə TOP-end nöqtələrini seçirik.

14) Per-tenant analitika və «ədalət»

Bütün əsas metriklər - 'tenant _ id/plan' etiketi ilə.
p99 quyruqlarında «ağır» müştərilərin payı; ayrı-ayrı limitlər/kvotalar və retraj büdcələri.
Ədalətli şeirinq: həddindən artıq yükləndikdə, «yüksək səsli» kirayəçilərin payını azaldır.

15) iGaming/Maliyyə Xüsusiyyətləri

'kyc _ level', 'risk _ tier', 'payment _ method' üzrə kəsiklər.
«Pul» yolları üçün SLI ('POST/deposits', 'POST/withdrawals'): aşağıda hədəf p95, ayrı-ayrı səhv büdcələri.
Time-to-Wallet metrikası (TTW), antifrodla avtoblokların payı, ödənişin konvertasiyası.
Audit: maliyyə hərəkətləri və antifrod qərarları üçün dəyişməz jurnallar.

16) Instrumentasiya: reallaşdırma təcrübələri

• `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`.
Kardinallıq: Pulsuz dəyərlərdən qaçın (user_id), «backets »/hash istifadə edin.
Exemplars: p95/p99 → trace klik histoqramlarına qoşulun.

17) Antipattern

Persentil əvəzinə orta; status-siniflərə bölünmə yoxdur.
Razılaşdırılmamış 'route '/' path' (dinamik ID etiketlərə «tikilmişdir»).
Yüksək kardinallığı olan etiketlər (raw user_id, IP).
Xarici provayderlərin ayrıca uçotunun olmaması (PSP/3rd-party).
«Səs-küy» (tək qapı və bir eşik).
p99, queue time istisna olmaqla (real deqradasiyanı maskalayır).

18) Prod-hazırlıq nəzarət siyahısı

• SLI/SLO və error-budget tərəfindən müəyyən edilmiş, biznes ilə razılaşdırılmışdır.
• latency vahid histoqramları və status sinifləri; p95/p99 daşbordlarda.
• Tam izləmə (OTel), qeydlərin/metriklərin/treyslərin korrelyasiyası.
• Burn-rate alertləri (iki pəncərəli), p99 və error-rate üzrə eşiklər.
• Per-tenant/per-plan kəsilmələri və dəyər hesabatları.
• Dashboard: Exec, Per-Route, Dependencies, Capacity, Abuse.
• Yük ssenariləri (burst/plato/stress), profil.
• Jitter ilə retraj siyasətləri; retrajların RPS-ə təsirinin hesablanması.
• Partnyorlar və ictimai müştərilər üçün SLA/SLO sənədləşdirilməsi.
• Retenshn/log maskalama, PII qorunması.

19) TL; DR

SLI/SLO və error-budget ətrafında müşahidə qurun, RED/USE ölçün, p95/p99 və «queue time» latency histogramlarını toplayın, perimetrdən DB-yə vahid trace-id paylayın, tail/adaptive-sampling istifadə edin, per-tenant saxlayın/dəyər kəsikləri və iki pəncərəli burn-rate-alerting. Tutumu növbə qanunları və biznes metrikasına təsiri ilə planlaşdırın; antipattern - persentil əvəzinə orta, yüksək kardinallıq və nəzərə alınmamış xarici asılılıqlar.