API de analiză și măsurători de performanță

1) De ce aveți nevoie de ea

• să dovedească punerea în aplicare a SLO și SLA
• gestionați lățimea de bandă și interogarea economică,
• localizați rapid degradarea (p99-cozi, rafale 5xx),
• prioritizeaza optimizarile impactului afacerilor.

Obiectiv: un singur model de observabilitate în care fiecare cerere este urmărită de la perimetru la DB cu identificatori comuni și SLI-uri consecvente.

2) Taxonomia metricii

Tehnic: RPS, latență (p50/p95/p99), rată de eroare (4xx/5xx), saturație (CPU, memorie, fișier-desc), timp de coadă.
Produs: operațiuni de succes/min, conversie în trepte (200/total), cotă limitată de rată (429), retribuții, segmente de utilizatori.
Cost: cost/cerere (CPU-ms + ieșire + cereri de baze de date), costul caracteristicii/endpoint, $/chiriaș, $/1k apeluri.

3) „Semnale de aur”: ROȘU și UTILIZARE

• Tarif - cereri/sec (după punctul final/chiriaș/plan).
• Erori - 4xx/5xx/429 fracții și absolute.
• Durata - p50/p95/p99 end-to-end și pe etape (ingress → app → DB → terță parte).

• Utilizare - sarcină CPU/IO/canal.
• Saturație - cozi (run-coadă, restanțe, așteptare DB).
• Erori - erori de driver/timeout.

4) Definiții și formule de bază

Disponibilitate SLI: '1 − (5xx + gateway_timeout )/ all_requests'.
SLI de succes: '2xx/( toate − 429_shadow)' (excluzând încuietorile din umbră).
Apdex: '(|T≤T| + 0. 5·|T≤4T| )/toate ', în cazul în care „T” este pragul țintă „bun”.
Amplificarea cozii: 'p99_total − max (p99_stage_i)' - contribuția cozilor/compoziției.
Bugetul de eroare (luna) la 99. 9%: "buget = 0. 1% perioada_timpul '.

Coșuri de percentilă recomandate de histograme de latență: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s] '.

5) SLI/SLO și alertă prin burn-rate

• Disponibilitate: ≥ 99. 9 %/30 zile.
• p95 latenta 'GET/portofel/echilibru' <150 ms; „POŞTĂ/PLĂŢI” <400 ms.
• Erori '5xx' <0. 2%. „429” (solid) <1% din traficul total.

• 2% din buget timp de 1 oră sau 5% timp de 6 ore → pagină inginerului.
• 10% pe zi → prioritizarea RCA.

6) Set de valori (ceea ce trebuie colectat este obligatoriu)

• 'http_requires_total {route, method, status, chiriaș, plan}'
• 'http_request_duration_seconds_bucket {route,...}' (histogramă)
• 'retries_total {reason}', 'rate_limited_total {key, policy}'
• Dimensiuni corp: 'request_bytes', 'response_bytes'

• 'db_client_requires_total {op, table}', 'db_latency_seconds_bucket {op}'
• 'cache_ops_total {op}', apeluri externe hit-rate cache: 'outbound_calls_total {provider, op}', latență/erori/termene de coadă/piscine: lungimi/întârzieri, UTILIZAREA resurselor active Lucrătorii: CPU, RSS, FD, GC pause

Etichete business: 'tenant_id', 'region', 'kyc_level', 'plan', 'feature_flag'.

7) Urme și corelații (OpenTelemetry)

W3C Trace-Context („traceparent”, „tracestate”) pe toate hameiul.
Span-s pe etape: intrare → authZ → app handler → DB/Redis → PSP/extern.
Atribute/etichete: "http. route ',' enduser. id', "chiriaş. id', "idempotenta. cheia „,” risc. scor '.
Exemplare: Puncte asociate privind graficele de latență/eroare cu id-ul de urme specific.

• cap-based 1-10% pentru trasee „normale”,
• pe bază de coadă pentru cozi (luați încet/eronat),
• adaptive pentru vârfuri și incidente.
• Bagaje: transportați „chiriaș ”/„ risc” pentru tăieri fără marcarea fiecărui eveniment.

8) Jurnale: structură și confidențialitate

JSON structurat; câmpurile necesare sunt 'ts', 'trace_id', 'span_id', 'route', 'status', 'latency_ms', 'tenant', 'user_id_hash'.
Politica PII: masca PAN/PII; refuza secretele/tokenurile.
Eșantionarea jurnalului: ridicată pentru cererile 4xx/5xx/429 și „lungi”.

9) Harta tabloului de bord (set minim)

1. Sumar: RPS, disponibilitate, rată de eroare, latenţă p95/p99, 429 share, buget pentru rata de inscripţionare.
2. Per-Route: Top Endoints by RPS/Error/Tail; compararea versiunilor (canar).
3. Per-Chiriaș/Plan: Încărcare/Cost/Error Leaders.
4. Sănătate dependentă: DB, cache, PSP/extern - latență, erori, saturație.
5. Capacitate: CPU/RAM/FD, cozi, piscină de conectare, GC, limite de containere.
6. Securitate/Abuz: 401/403, 429/politicieni, felii geo/ASN, spikes retry.

10) Alerte (prag și tendință)

'error_rate {route}'> 2% (5 minute) și RPS> N → pager.
'p99_latency {critical}'> pragul țintă (10 minute).
"burn_rate 'by budget (vezi § 5).
DB 'timeouts'/'blocaje' sau creștere 'coadă _ timp'> X ms.
Furnizori externi: 'outbound_5xx_rate {provider}'> 1% + dependent de SLO.

11) Planificarea și performanța capacitivă

Legea lui Little: 'L = λ· W' (lungimea medie a cozii = traficul × timpul mediu).
Ținta p95 este descompusă: 'intrare + aplicație + DB + coadă + externă'.
Bugetul de concurență: fixați numărul maxim de operațiuni de scriere simultană.
Metrica bugetară: „CPU ms per request”; păstrăm o marjă de 30-50% până la vârf.
Interacțiunea cu limita ratei: măsurarea proporției cererilor la „plafonul” contingentului și a impactului asupra latenței.

12) Încărcare și controale sintetice

Tipuri: sarcină de bază, explozii × 10, „pași”, platouri pe termen lung, stres/haos (uciderea nodurilor, întârzieri în rețea), sintetice în funcție de scenariile critice ale clienților.
Profilare: CPU/allocare/blocare-contention, N + 1 (SQL/HTTP), coduri lente.
Controlul regresiei: compararea erorilor p95/p99/înainte/după lansare (canar).

13) Cost-Observabilitate

Cost metrics: 'cpu_ms', 'egress_bytes', 'db_calls', '$ per 1k requests'.
Alocarea la punctul final/chiriaș/caracteristică: etichete de facturare de la orchestrator + măsurători de încărcare → raport economic unitate API.
Algoritm de optimizare: selectați TOP-endpoints de către produsul „trafic × cost × (p95 − țintă)”.

14) Analiza per chiriaș și „justiție”

Toate valorile cheie sunt etichetate „chiriaș _ id/plan”.
Ponderea clienților „grei” în cozile p99; limite/cote individuale și bugete retrase.
Forfecare echitabilă: atunci când este supraîncărcat, reducem ponderea chiriașilor „cu profil înalt”.

15) Specificul iGaming/Finanțe

Secțiuni prin 'kyc_level', 'risk_tier', 'payment_method'.
SLI pentru căile „money” („POST/depuneri”, „POST/retrageri”): p95 țintă mai mică, bugete separate de erori.
Măsurători Time-to-Wallet (TTW), cota de blocări automate antifraudă, conversia plăților.
Audit: jurnale imuabile pentru acțiuni financiare și decizii antifraudă.

16) Instrumentație: Practici de implementare

• '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}'

Etichete: 'route', 'method', 'status_class', 'tenant', 'region', 'version', 'canary', 'provider', 'db_table'.
Cardinalitate: evitați valorile libere (user_id), utilizați „găleți „/hash.
Exemplare: conectați-vă la histogramele p95/p99 → făcând clic pe urmă.

17) Antipattern

Mediu în loc de percentile; nici o împărțire în clase de stare.
Inconsecvent „traseu ”/„ cale” (ID-urile dinamice sunt „cusute” în etichete).
Etichete cu cardinalitate ridicată (user_id brută, IP).
Nu există contabilitate separată a furnizorilor externi (PSP/3rd-party).
Alerte prin „zgomot” (o singură fereastră și un prag).
p99, cu excepția timpului de coadă (măști de degradare reală).

18) Lista de verificare Prod Readiness

• SLI/SLO și bugetul de eroare definit, de acord cu afacerea.
• Histograme de latență unică și clase de stare; p95/p99 pe tablouri de bord.
• Urme complete (OTel), corelație jurnal/metric/urmă.
• Alerte burn-rate (două ferestre), praguri p99 și rata de eroare.
• Per-chiriaș/per-plan secțiuni și rapoarte de costuri.
• Tablouri de bord: , Per-Route, Dependențe, Capacitate, Abuz.
• Scenarii de încărcare (izbucnire/platou/stres), profilare.
• Jitter Retries Policies; contabilizarea efectului retroactivelor asupra SPR.
• Documentație SLA/SLO pentru parteneri și clienți publici.
• Mascare de retenție/jurnal, protecție PII.

19) TL; DR

Construiți observabilitatea în jurul SLI/SLO și bugetul de eroare, măsurați RED/USE, colectați histograme de latență cu p95/p99 și timpul de coadă, distribuiți un singur trace-id din perimetru în DB, utilizați coada/adaptive-sampling, țineți per chiriaș/reduceri de costuri și două ferestre burn-rate-alert. Capacitatea planului în conformitate cu legile de coadă și impactul asupra metricii de afaceri; antipatterns - mediu în loc de percentile, cardinalitate ridicată și dependențe externe nescontate.