Operazioni e Gestione → Metriche delle prestazioni
Metriche delle prestazioni
1) A cosa servono le metriche delle prestazioni
Le prestazioni sono la capacità del sistema di fornire SLO mirati in base ai tempi di risposta e alla larghezza di banda a costi contenuti. Senza metriche non è possibile:- rilevare il degrado prima degli incidenti,
- prevedere capacità e budget,
- confrontare le soluzioni alternative (cache vs database, gRPC vs REST),
- gestire le regressioni dopo i rilasci.
I principi sono: un unico dizionario di metriche, aggregazione per percento (p50/p90/p95/p99), conteggio separato di percorsi caldi e freddi, contesto (versione, regione, provider, dispositivo).
2) Tassonomia metriche
2. 1 Cornici SRE base
Quattro segnali d'oro: Latency, Traffic, Errors, Saturation.
RED (per microservizi): Rate, Errors, Duration.
USA (per il ferro): Utilization, Saturation, Errors.
2. 2 Livelli
Infrastruttura: CPU, RAM, disco, rete, contenitori, nodi.
Piattaforma/Servizi: endpoint API, code, cache, database, pneumatici eventi.
Esperienza dei clienti: Web Vitals, mobile SDK, streaming, CDN.
Piattaforma data: ETL/ELT, strip, vetrine, BI ritardi.
Flow critici aziendali: autorizzazioni, KYC, depositi/pagamenti, round game.
3) Catalogo delle metriche chiave e delle formule
3. 1 API e microservizi
RPS (Requests per second).
Latency p50/p95/p99 (ms) - preferibilmente «end-to-end» e «backend-only».
Errore Rate (%) = 5xx + convalidabili 4xx/tutte le richieste.
Saturation: lunghezza media della coda dei worker, in-flight delle query.
Cold Start Rate (per FaaS).
Throttling/Dropped Requests.
SLO esempio: p95 latency 250 ms con RPS fino a 2k nella regione EU-East; Errori ≤ 0. 5%.
3. 2 Database
QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (replica), Checkpoint/Flush time, Autovacuum lag.
Hot Keys/Skew è il top-N delle chiavi di carico.
La formula Query kernel è QPS/ .
3. 3 Cache e CDN
Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.
3. 4 Code/striam
Ingress/egress msg/s, Consumer Lag (messaggi/ora), Rebalance rate.
Processing Time p95, DLQ Rate.
3. 5 Infrastruttura/contenitori
CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).
3. 6 Client Web (UX)
Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency.
3. 7 Client mobile
App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Offline success rate (operazioni di cache).
3. 8 Data-piattaforma e report
Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Cost per TB processed, Skew per partenze, Late events%.
BI Time-to-Render p95 per i dashboard chiave.
3. 9 Flow critici di dominio (iGaming come esempio)
Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.
4) Normalizzazione, percezione e attribuzione
Percentili contro media: fissiamo p50/p90/p95/p99 - la media allevia il dolore di punta.
Tagli: versione dell'applicazione, regione, provider, canale di rete (4G/Wi-Fi), dispositivo.
Correlazione: colleghiamo «backend-only» e «real-user» le metriche per le catene di causale.
Eccplars/Trace - Colleghiamo i percettori estremi ai tracciati.
5) Soglie e alert (griglia modello)
Latency p95 (core API): warning> 250 ms, critical> 400 ms 5 minuti consecutivi.
Error rate: warning > 0. 5%, critical> 2% (endpoint, non globale).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.
Usiamo soglie statiche + adattive (stagionalità, modelli diurni), deduplicazione e raggruppamento di alert per servizi/rilascio.
6) Test delle prestazioni
Tipi: baseline, stress, lungo (soak), caos (degrade links/PSP).
Profili di carico: trade reali (distribuzione-based), burst, picchi regionali.
Obiettivi: raggiungimento di SLO con operazioni mirate RPS e mix, convalida backpressure.
Metriche di progone: Throughput, Errore%, p95 latency, pausa GC, CPU throttle, queue lag, cost/run.
Regola di regressione: il rilascio è considerato un successo se p95 non è peggiorato> 10% con un profilo uguale e il costo della richiesta (CPU-ms/query) non è aumentato> 15%.
7) Pianificazione della capacità e costi/prestazioni
Demand model: RPS ore x media lavoro/query (CPU-ms, IO-ops).
Headroom: 30-50% di riserva per percorsi critici, auto-scaling per P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. Miglioramenti LCP.
Cache/Denormalizzazione: conta «cache ROY» = (risparmio CPU-ms - costo cache).
Regioni calde e fredde: offload in CDN/edge, replica solo lettura.
8) Pratiche di osservazione e profilassi
Tracciati: trace-ID distribuiti attraverso tutti gli hop's; il sempilamento è intelligente (tail-based).
Metrica: Prometheus/OpenTelemetry, una sola nota di nomi e etichette.
Loghi: correlazione trace/span, budget al rumore logico, modifica PII.
Profilatori: CPU/Heap/Alloc/Lock profiles, profilazione continua (eBPF).
Istanze campione: colleghiamo p99 picchi a specifici span/SQL/PSP-call.
9) Metriche di rilascio e comandi (per la completezza)
DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
SPAZIO: soddisfazione, prestazioni, attività, comunicazione, efficienza.
Queste metriche non riguardano il ferro, ma influenzano direttamente la sostenibilità delle prestazioni.
10) Anti-pattern
Insegui media: ignora p95/p99.
«Global» errato rate, nasconde endpoint dolorosi.
Senza l'assegnazione delle versioni, non è possibile catturare la regressione del client.
Alert-spam - soglie senza isteresi e correzione stagionale.
Ottimizzazione alla cieca: nessuna profilassi o traccia.
Combinazione tra UX e backend latency: conclusioni errate per esperienza client.
11) Assegno fogli
Standard di metriche unificate
- Dizionario di metriche con formule, unità, proprietari
- Percentili obbligatori p50/p90/p95/p99
- Correlazione trace e loga-correlazione
- Tag: regione, versione, provider, dispositivo, canale di rete
- Soglie con isteresi e deduplicazione
Prima del lancio
- Baseline p95/p99 su stage e vendette
- Traffico canarino + confronto metriche A/B
- Flag Fiech con rigetto rapido
- Piano di sorveglianza (osservability runbook)
Regolare
- Ruota i top-N più lenti di query/SQL
- Controllo dei criteri cache e TTL
- Verifica di Freshness e delle repliche del database
- Test di degrado dei provider esterni (PSP, KYC)
12) Mini playbook (esempio)
Degrado p95/api/payments
1. Incrocia il% e i timeout PSP esterni.
2. Controlla il consumer lag code Colleback.
3. Visualizzare trace di esempi p99: lo stretto di SQL/HTTP?
4. Abilita la cache di guide/limiti, riduce N + 1.
5. Budget: aumentare temporaneamente del 20% le risorse del worker, includere l'autoscale.
6. Post-fix: indice per (psp _ id, status, created _ at), retrai-jitter.
Crescita del RepLag nel database
1. Verifica richieste pesanti e transazioni lunghe.
2. Aumenta il parallelismo della replica, tinge checkpoint.
3. Offload di sola lettura nella cache/replica.
4. Con le finestre di punta, denorm parziale + batch.
13) Esempi di formule/SQL (semplificato)
Errore Rate per endpoint
sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;
Latency p95 (TDigest/Approx)
sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;
Consumer Lag (ora)
sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;
Web LCP p75
sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;
14) Incorporazione e reporting dei dashboard
Carte KPI: p95 latency, errore%, RPS, saturation con trend WoW/DoD.
Top N «peggiori» endpoint/SQL/risorse, cliccabile drill-down-trace.
La correlazione delle versioni del client è la versione p95 LCP/INP della conversione.
Mappa del mondo: geo-latency (CDN), PSP latency per regione.
Dashboard SLO: parte del tempo in SLO, uscite da SLO, bilancio degli errori.
15) Riepilogo
Le metriche delle prestazioni sono una disciplina di sistema: un unico dizionario, una perforazione, un'attribuzione, una buona osservabilità e un SLO rigoroso. Combinando i segnali tecnici (latitanza, lagi, kash hit) e alimentari (tempo KYC, deposito p95, LCP), si gestisce la qualità dell'esperienza e il costo della consegna - prevedibile e scalabile.