Monitoraggio e observability: garantire uptime nei picchi di traffico
Ore 20:59. Promo live. Notifiche push partite. Traffico x10 in 90 secondi. La home risponde, ma i percorsi critici vanno lenti. Il p99 sale. Gli errori 5xx iniziano a colpire il checkout. In war room c’è silenzio. Una persona guarda la latenza del DB. Un’altra controlla il cache hit su CDN. La domanda è semplice: reggiamo l’onda o no? Qui il monitoraggio classico non basta. Serve vera observability per capire il “perché” in tempo e non dopo il blackout.
Mini check: sei pronto ai picchi?
- Hai SLO chiari per uptime e latenza su percorsi critici?
- Hai test sintetici attivi prima, durante e dopo l’evento?
- Hai limiti e quote per dipendenze esterne (API, DB, terze parti)?
- Hai runbook brevi per incident e rollback?
- Hai dashboard “modalità picco” con p95/p99, code, retry, cache?
- Hai fatto una prova a secco (game day) la settimana prima?
Monitoraggio vs observability, in parole semplici
Monitoraggio dice cosa e quando: “errori 5xx saliti alle 21:02”, “CPU 90%”. Observability dice perché: “cache tiepida, DB in coda, retry in tempesta”. Il primo usa metriche e soglie. Il secondo unisce metriche, log e tracce end‑to‑end. Con le tracce vedi la catena: client → edge → gateway → servizio → DB. Vedi dove si allunga il tempo e dove perdi richieste.
Per fare scelte sane, leggi la guida SRE sugli SLO. Parti da SLI semplici: disponibilità del percorso di pagamento, latenza p99 della ricerca, tasso errori nel login. Poi costruisci SLO con budget di errore e allerta su sintomi, non su CPU.
Un breve post‑mortem: cosa è andato storto e come l’abbiamo risolto
Scenario reale. Evento serale. Il traffico sale in 3 minuti. La CDN non ha tutto in cache. I primi minuti vanno a caldo sul backend. Il DB legge troppo, il pool si satura, la coda di messaggi cresce. I client vedono 1,2% di 5xx e p99 oltre 1,5 s. Gli alert scattano in ritardo perché erano su media p95, non su p99 e non su coda.
Segnali chiave che abbiamo mancato: cache hit ratio in calo nelle prime decine di secondi, retry rate in aumento lato client, latenza “tail” del DB (p99.9) che sale prima di tutto il resto. Il nostro autoscaling era reattivo, non predittivo. Le nuove VM erano lente a scaldarsi. Le code non avevano backpressure; i retry hanno peggiorato il carico.
Correzioni fatte: dashboard per “modalità picco” con focus su p99 e depth delle code; warm‑up della cache a ridosso dell’evento; rate limiting sugli endpoint rumorosi; circuit breaker verso servizi lenti; alert guidati da sintomi. Per la scelta delle metriche abbiamo usato il metodo RED per le API (Rate, Errors, Duration) e il metodo USE per risorse (Utilization, Saturation, Errors). MTTR sceso da 38 a 12 minuti nel successivo evento.
Quali segnali guardare quando l’onda arriva
I valori qui sotto sono di partenza. Servono taratura sul tuo dominio e sui tuoi dati storici. Conta soprattutto la coerenza: stessi SLI, stessa finestra, stesso modo di misurare. Gli SLO in picco possono essere diversi dagli SLO “giorno normale”.
| Latenza p99 API critiche | Il “tail” uccide l’esperienza in picco | p99 < 800 ms a +5× traffico | Gateway, service mesh | Prometheus, APM, tracce OTel |
| Error rate 5xx | Segnale di rottura reale per l’utente | < 1% durante evento | Edge, API gateway | APM, synthetic |
| Error rate 4xx anomali | Può segnalare throttling o WAF troppo stretto | Baseline stabile, spike investigare | CDN/WAF, gateway | CDN logs, SIEM |
| CPU/RAM/IO saturazione | Limite fisico, causa code e timeout | CPU < 70%, IO wait < 5% | VM/container, nodi DB | Node exporter, Cloud metrics |
| Depth e tempo nelle code | Backlog = ritardo reale per utenti | Tempo in coda < 200 ms | Broker (SQS, Kafka, Rabbit) | Exporter broker, APM |
| Retry rate e throttling | Storm di retry amplifica il carico | Retry < 2%, 429 sotto controllo | Client, gateway, servizi | Log correlati a trace‑id |
| Cache hit ratio | Protegge backend in picco | > 90% per oggetti caldi | CDN, cache applicativa | CDN analytics, Grafana |
| DB tail latency (p99) | Il collo di bottiglia più comune | < 50 ms letture, < 100 ms scritture | DB e pool connessioni | DB exporter, APM |
| RUM LCP/INP in picco | Impatto reale lato utente | LCP < 2.5 s, INP < 200 ms | Browser utenti | RUM, Web Vitals |
| Uptime sintetico dei percorsi | Testa fine‑a‑fine, 24/7 | > 99.9% nel periodo evento | Probes da più regioni | Synthetic, cron probes |
| CDN/WAF rate e challenge | Filtra picchi malevoli e bot | Challenge success stabile | Edge/CDN | CDN logs, SIEM |
Antipattern comuni e mosse che aiutano davvero
Antipattern da evitare: monolite senza backpressure; retry aggressivi senza jitter; un solo DB condiviso e senza limiti di connessioni; niente warm‑up per cache e JVM; scaling solo reattivo; allarmi su CPU al posto dei sintomi utente. Tutto questo rende l’incidente più lungo e più costoso.
Mosse utili al bordo: CDN con cache shield e regole su TTL per oggetti caldi; immagini e JSON compressi; WAF con regole per picchi stagionali. Questo aiuta a mitigare i picchi al bordo e a lasciare il core pulito nei primi minuti.
Protezione applicativa: token bucket e rate limiting con NGINX; circuit breaker per dipendenze lente; timeout corti e sensati; risposte parziali (degrada con grazia). Spesso basta limitare due endpoint rumorosi per salvare il resto.
Architettura per assorbire l’onda: code e lavori asincroni tra front e servizi pesanti; bulkhead per isolare aree; pool di connessioni con limiti; read‑replica per letture. Vedi come progettare code resilienti. Fai autoscaling con warm‑up predittivo: accendi risorse prima del picco, non dopo.
Strumentare bene: dal codice alla dashboard
Metti tracce dappertutto con OpenTelemetry in pratica. Propaga trace‑id tra servizi e inseriscilo nei log. Così colleghi log, metriche e tracce in un solo filo. Aggiungi tag chiari: servizio, versione, azione, utente anonimo/ID sessione (se le policy lo permettono).
Metodo semplice per dashboard: RED per API (rate, error, duration) e USE per host (utilization, saturation, errors). Dividi dashboard “giorno normale” e “modalità picco”. Nella seconda tieni in alto p99, coda, cache hit, retry, quota terze parti, error budget. Evita 100 grafici: 12 ben fatti bastano.
Per ispirazione su layout e SLO, guarda le best practice per dashboard SLO. Ricorda di segnare gli “event marker” (promo, partite, lanci) sulla timeline: capire il contesto riduce MTTR.
SLO, budget di errore e alerting che non fa rumore
SLI misurano, SLO fissano l’obiettivo, il budget di errore ti dice quanta rottura puoi “spendere”. In un evento breve puoi accettare un po’ più di latenza, ma pochi errori reali. Esempio: durante 2 ore di picco, uptime 99.95% e p99 < 800 ms. Fuori picco, p99 < 400 ms. L’importante è dichiararlo prima e allineare tutti.
Gli alert devono colpire i sintomi. Primo livello: “p99 sopra soglia 10 min”, “5xx > 1% 3 min”, “tempo in coda > 200 ms”. Secondo livello: “error budget bruciato al 50%”. Per policy e pratica vedi error budget e policy di alert. Tieni un canale di on‑call chiaro e una catena di escalation corta. Taglia il rumore con regole di dedup e silenzi in finestra evento.
Preparazione al picco: checklist operativa
- Piano evento: percorsi critici, SLO in finestra, limiti per dipendenze, freeze deploy 24–48 h prima.
- Warm‑up: CDN e cache applicative con i top oggetti; pool DB già carico; autoscaling predisposto.
- Test sintetici: login, ricerca, checkout, pagamento. Da 3 regioni, ogni 1–2 min.
- Feature flags: abilita modalità degradata pronta (immagini più piccole, niente raccomandazioni, coda visibile).
- Quote e limiti: N richieste/min per IP/utente su endpoint rumorosi. Backoff con jitter sui retry.
- Runbook brevi: 1 pagina per rollback, switch cache, riduzione funzionalità. Chi fa cosa in 5 minuti.
- War room: canale unico, grafici pin in alto, marker orari. Un owner per ogni dominio (edge, API, DB, code).
- Incident response: ruoli, escalation, turni on‑call. Risorse utili: incident response efficace.
- Post‑evento: retro breve, dati in chiaro, azioni con scadenza. Aggiorna SLO e alert.
Settori con picchi forti e rapidi, come scommesse live e casinò online, hanno pattern “a onda” durante partite e finali. Qui contano molto edge, cache e controllo del retry. In giornate così, un comparatore indipendente aiuta gli utenti a scegliere piattaforme solide. Un esempio neutro è https://onlinecasinofans.com/, utile come guida alle recensioni e alla reputazione dei siti. Per chi gestisce il traffico, questi eventi sono ottimi stress test: prepara canary, verifica SLI reali e aggiorna i limiti dopo ogni match.
Come scegliere gli strumenti senza pentirti dopo
APM, log, tracce, synthetic: scegli con criteri chiari. Supporto nativo a OpenTelemetry, query veloci, avvisi SLO pronti, routing alert flessibile. Guarda il costo per GB o per evento e il limite di cardinalità. Servono data retention diversa per “crudo” e per “aggregato”. Integrazioni con on‑call e ticket sono un plus.
Per i log, pianifica ingest a costo giusto: riduci il rumore in origine, usa sampling e filtri. Idee pratiche qui: strategie di logging a costo sostenibile. Se stai su cloud, valuta i pilastri di affidabilità: pilastro di affidabilità AWS. E ascolta la community: i talk pratici da SREcon sono mini‑casi molto utili.
FAQ rapide
Qual è la differenza pratica tra monitoraggio e observability?
Monitoraggio guarda soglie e stato. Observability unisce metriche, log e tracce per rispondere a domande nuove senza codice extra. Con le tracce trovi il collo di bottiglia in minuti, non in ore.
Quali SLI iniziare a misurare per un sito consumer in promo?
Uptime e p99 dei percorsi: home → ricerca → scheda → carrello → pagamento. Aggiungi errori 5xx e cache hit. Poi code e tail DB. Parti da questi cinque.
Come evitare tempeste di retry?
Imponi limiti per client, usa backoff con jitter, metti circuit breaker verso servizi lenti, e segnala al client quando riprovare. Traccia il retry rate come SLI.
Meglio scale‑out automatico o warm‑up programmato?
In picco prevedibile, warm‑up vince. Accendi risorse prima dell’evento. Tieni anche autoscaling per variazioni impreviste. Mix dei due è la scelta sicura.
Come ridurre MTTR durante i picchi?
Dashboard “picco” con pochi grafici chiave, marker evento, runbook chiari, on‑call pronto. Alert su sintomi utente, non su infrastruttura. Tracce con trace‑id nei log.
I log ad alta cardinalità: quando fermarsi?
Se la dimensione esplode e non porti insight, campiona. Tieni tutto per errori e per percorsi critici. Per il resto, aggrega e conserva solo quanto serve all’analisi.
Conclusione: tre mosse per la prossima settimana
- Costruisci una dashboard “modalità picco” con p99, errori, cache hit, depth code, retry rate. Niente fronzoli.
- Scrivi o aggiorna 2 runbook: rollback rapido e riduzione funzionalità. Prova a secco di 30 minuti.
- Definisci SLO e budget di errore per il prossimo evento. Allinea team prodotto e supporto.
L’onda arriva quando meno te lo aspetti. Con segnali giusti, limiti chiari e strumenti semplici, puoi restare online e dare fiducia agli utenti anche nel momento più caldo.
Note autore: SRE/Head of Platform, 10+ anni tra e‑commerce, streaming e gaming. Certificazioni cloud e vari talk interni. Articolo rivisto da un technical editor. Dati e soglie sono esempi: calibra sul tuo contesto. Ultimo aggiornamento: .