API di analisi e metriche delle prestazioni

1) Perché è necessario

• prova di esecuzione SLO e SLA,
• gestire la larghezza di banda e l'economia delle richieste,
• localizzare rapidamente il degrado (code p99, picchi 5xx),
• Priorità per l'ottimizzazione dell'impatto aziendale.

Obiettivo: un unico modello di osservabilità in cui ogni richiesta viene monitorata dal perimetro al database con identificatori comuni e SLI coerenti.

2) Tassonomia metriche

Tecnico: RPS, latenza (p50/p95/p99), error rate (4xx/5xx), saturation (CPU, memory, file-desc), queue time.
Prodotti: operazioni di successo/min, conversione del passo (200/total), rate-limited (429), retrai, segmenti personalizzati.
Costo: cost/richiest (CPU-ms + egress + richieste di database), costo fici/endpoint, $/tenant, $/1k chiamate.

3) «Segnali d'oro»: RED e USA

• Rate - query/secondi (per endpoint/tenant/piano).
• Errors - 4xx/5xx/429 quote e assoluti.
• Duration è p50/p95/p99 end-to-end e per stadio (ingress-app DB terzi).

• Utilization - Caricamento CPU/IO/canale.
• Saturation - Code (run-queue, backlog, DB wait).
• Errors - Errori driver/timeout.

4) Definizioni di base e formule

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Success SLI: '2xx/( all - 429 _ shadow)' (esclusi i blocchi shadow).
Apdex: `(|T≤T| + 0. 5·|T≤4T| )/all ", dove" T "è il target" buono ".
Tail amplificazione: 'p99 _ total - max (p99 _ stage _ i)' è il contributo delle code/composizioni.
Errore budget (mese) a 99. 9%: 'budget = 0. 1% tempo _ periodo '.

I bin persistenti raccomandati di istogrammi latency: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO e alerting per burn-rate

• Disponibile: ≥ 99. 9 %/30 giorni.
• p95 latitanza «GET/wallet/bilance» <150 ms; «POST/payments» <400 ms.
• Errori dì 5xx "<0. 2%. '429' (solido) <1% del traffico totale.

• Il 2 per cento del budget di un'ora o il 5 per cento in un ingegnere.
• 24 ore per la priorità RCA.

6) Insieme di metriche (che è obbligatorio raccogliere)

• `http_requests_total{route,method,status,tenant,plan}`
• 'http _ sollest _ duration _ seconds _ bucket {route,...}' (istogramma)
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• Dimensioni del corpo: 'sollest _ byties', 'response _ byties'

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• 'cache _ ops _ total {op}', hit-rate cache di chiamate esterne: 'outbound _ calls _ total {provider, op}', latency/errori/timeout coda/pool: lunghezze/ritardi, worker attivi USA risorse: CPU, RSS, FD, GC Interruzioni

Etichette aziendali: «tenant _ id», «region», «kyc _ level», «plan», «feature _ flag».

7) Traccia e correlazione (OpenTelemetry)

W3C Trace-Text ('traceparent', 'tracestate') su tutti gli hop.
Span-i-stadi: ingress- app handler DB/Redis-PSP/esterno.
Attribute/etichette: 'http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Explars: collegare i punti sui grafici latency/errore a trace-id specifici.

• head-based 1-10% per i percorsi «normali»,
• tail-based per le code (prendiamo lenti/errate),
• adattativo per picchi e incidenti.
• Baggage: migrazione «tenant »/« risk» per i tagli senza contrassegnare ogni evento.

8) Logi: struttura e privacy

JSON strutturato; i campi obbligatori sono «ts», «trace _ id», «span _ id», «route», «status», «latency _ ms», «tenant», «user _ id _ hash».
Criterio PII: maschera PAN/PII; Vietate i segreti/token.
Il sampling è alto per le query 4xx/5xx/429 e lunghe.

9) Mappa dei dashboard (set minimo)

1. Exec-Summary: RPS, Availability, Errore-rate, p95/p99 latency, 429 quote, burn-rate budget.
2. Per-Route: top endoint RPS/errori/coda; confronto di versioni (canarino).
3. Per-Tenant/Plan: leader in carico/costo/errore.
4. Dipendency Health: DB, cache, PSP/esterno - latency, errori, saturation.
5. Capacity: CPU/RAM/FD, code, connection pool, GC, limiti dei contenitori.
6. Sicurezza/Abuse: 401/403, 429/regole, taglio geo/ASN, picchi di retrai.

10) Alert (soglie e tendenze)

'errore _ rate {route} '> 2% (5 minuti) e RPS> N →.
'p99 _ latency {critical}'> soglia di destinazione (10 minuti).
'burn _ rate'in base al budget (vedere l'articolo 5).
DB «timeouts »/« deadlocks» o «queue _ time»> X mc.
Provider esterni: 'outbound _ 5xx _ rate {provider}'> 1% + dipendenti SLO.

11) Pianificazione e prestazioni della capacità

La legge Little è «L = world· W» (lunghezza media della coda = traffico x tempo medio).
Il p95 di destinazione è «ingress + app + DB + esternal + queue».
Concurrency budget: fissa il massimo delle operazioni write simultanee.
Budget-metrica: «ms CPU per richiesta»; teniamo una riserva del 30-50% al picco.
Interazione rate-limit: misura la percentuale di query del soffitto di quota e l'impatto sulla latitanza.

12) Controlli di carico e sintetici

Tipi: carico di lavoro di base, burst x 10, «gradini», piani a lungo termine, stress/chaos (uccidere nodi, ritardi di rete), sintetico in scenari critici per i clienti.
Profilazione: CPU/alloc/lock-content, N + 1 (SQL/HTTP), codici lenti.
Controllo regressione: confronto p95/p99/errori prima/dopo il rilascio (canaresco).

13) Costo (Cost-Observability)

Metriche di costo: «cpu _ ms», «egress _ byties», «db _ calls», «$ per 1k sollests».
Allocazione per endpoint/tenant/fish: tag di bollo dell'orchestratore + metriche di carico → Rapporto di unit economy API.
Algoritmo di ottimizzazione: scegliamo gli endpoint TOP per «traffic x cost x (p95 - obiettivo)».

14) Per tenente analista e «giustizia»

Tutte le metriche chiave sono con etichetta «tenant _ id/plan».
La quota di clienti «pesanti» nelle code p99; limiti/quote separati e budget dei retrai.
Giusto Shayring, in caso di sovraccarico, ridurremo la quota di affittacamere.

15) Specificità iGaming/finanza

Tagli per «kyc _ level», «risk _ tier», «payment _ method».
SLI per i percorsi «cash» («POST/deposits», «POST/withdrawals»): sotto i target p95, singoli bilanci di errore.
Metriche Time-to-Wallet (TTW), quota di blocchi automatici con antifrode, conversione dei pagamenti.
I registri immutabili per le azioni finanziarie e le decisioni antifrode.

16) Strumenti: pratiche di implementazione

• `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`.
Cardinalità: evita i valori liberi (user _ id), usa i «bustini »/hash.
Eccplars - Collegare un clic su trace agli istogrammi p95/p99.

17) Antipattern

Media invece dei percentili; nessuna suddivisione in stato-classi.
«route »/« path» non coerenti (ID dinamico «puntato» nelle etichette).
Etichette ad alta radicalità (raw user _ id, IP).
Nessuna contabilità separata dei provider esterni (PSP/3rd-party).
Alert per rumore (una sola finestra e una sola soglia).
p99 senza contare la queue time (maschera il degrado reale).

18) Elenco di controllo prod-pronto

• Definiti SLI/SLO e errore-budget, coerenti con il business.
• Istogrammi comuni latency e status-class; p95/p99 sui dashboard.
• Traccia completa (OTEL), correlazione tra logi/metriche/trailer.
• Alert burn-rate (due finestre), soglie p99 e error-rate.
• Per tenente/per-piano tagli e rapporti di costo.
• Dashboard: Exec, Per-Route, Dipendencies, Capacity, Abuse.
• Script di carico (burst/platea/stress), profilassi.
• Policy retraes con jitter; tenere conto dell'impatto dei retrai su RPS.
• Documentazione SLA/SLO per partner e clienti pubblici.
• Retenschn/occultamento dei fogli, protezione PII.

19) TL; DR

Costruisci un'osservazione attorno a SLI/SLO e error-budget, misura RED/USE, raccogli istogrammi latency da p95/p99 e «queue time», distribuisci un unico trace-id dal perimetro al BD, usa tail/adattivo-sampling, tieni per-tenant/stop e tagli burn-rate-alerting a due finestre. Pianificare la capacità secondo le leggi di coda e l'impatto sulle metriche aziendali. antipattern - media invece di percentili, alta cardinalità e dipendenze esterne non note.