Va bene, amici. Chris Wade qui, di nuovo nelle trincee digitali per agntlog.com. Oggi non stiamo semplicemente esplorando un concetto; ci stiamo addentrando in qualcosa che, sinceramente, non mi fa dormire la notte. Non in modo negativo, di solito. Più in un modo tipo “e se mi fossi perso quell’unica cosa?”. Stiamo parlando di alerting, in particolare, di come spesso ci sbagliamo, e di come sistemarlo prima che ci costi più della semplice mancanza di sonno.
La data attuale è 29 marzo 2026. E se sei come me, la tua inbox, Slack, o qualunque piattaforma di comunicazione tu utilizzi è probabilmente un cesspool traboccante di notifiche. La maggior parte di esse è inutile. E questo, miei amici, è l’angolo tempestivo su cui ci concentreremo oggi. Siamo diventati così bravi a raccogliere dati, così abili a monitorare ogni piccolo movimento nei nostri sistemi, che abbiamo completamente dimenticato lo scopo di un avviso: dirci quando qualcosa ha veramente bisogno della nostra attenzione, proprio adesso.
L’epidemia di affaticamento da avvisi: la mia battaglia personale
Essere reali per un attimo. Il mio primo vero lavoro dopo il college, facevo parte di un piccolo team che gestiva una piattaforma SaaS abbastanza complessa. Eravamo giovani, ambiziosi e completamente convinti che maggiori avvisi equivalessero a maggiore controllo. Oh, quanto eravamo naïf. Ogni picco della CPU oltre il 70%, ogni assegnazione di memoria che superava una certa soglia, ogni singolo errore HTTP 500 – tutto ciò attivava un avviso. E questi non erano semplicemente indicatori sul cruscotto; erano chiamate di PagerDuty, inondazioni di email e tempeste nei canali Slack.
Ricordo una mattina di martedì, verso le 3 del mattino. Il mio telefono vibrava sul comodino. PagerDuty. Avviso critico. “Utilizzo del pool di connessioni al database oltre l’80%.” Il mio cuore ha saltato un battito. Ho cercato il mio laptop, mi sono collegato con VPN e ho iniziato a scavare. Si è scoperto che era un lavoro di backup notturno programmato che brevemente, per circa 15 minuti, aveva aumentato l’utilizzo del pool di connessioni. Era un comportamento completamente normale, previsto. Ma poiché non avevamo considerato il contesto, poiché non avevamo sintonizzato i nostri avvisi, stavo fissando uno schermo alle 3 del mattino senza alcun buon motivo.
Quello è stato un momento cruciale per me. Non si trattava solo del sonno perso; riguardava la desensibilizzazione che ne seguì. Dopo alcune settimane di falsi allarmi, gli avvisi critici autentici iniziarono a confondersi. Questo è l’affaticamento da avvisi. È insidioso. Trasforma il tuo sistema di monitoraggio altamente sintonizzato in rumore di fondo, e quando scoppia un vero incendio, sei meno propenso a notarlo, per non parlare di rispondere efficacemente.
Oltre la soglia: cosa rende un buon avviso?
Quindi, se “più avvisi” non è la risposta, quale lo è? Per me, un buon avviso ha tre caratteristiche fondamentali:
- Azionabile: Ti dice qualcosa su cui puoi effettivamente agire.
- Tempestivo: Ti colpisce quando conta, non troppo presto, non troppo tardi.
- Contestualizzato: Fornisce abbastanza informazioni per comprendere il problema senza scavi approfonditi.
La maggior parte di noi è abbastanza brava nella parte “tempestiva”, grazie agli strumenti di monitoraggio moderni. Ma “azionabile” e “contestualizzato” sono dove spesso cadiamo. Impostiamo un avviso per “utilizzo della CPU > 90% per 5 minuti.” Ok, azionabile? Forse. Se significa un processo fuori controllo, certo. Ma cosa succede se è un lavoro batch che dovrebbe massimizzare la CPU per 10 minuti ogni giorno alle 13:00? Qui entra in gioco il contesto.
Da sintomi a malattia: avvisare sugli impatti
Invece di avvisare solo su metriche grezze, dobbiamo cambiare il nostro modo di pensare per avvisare sugli impatti. Cosa significa un’alta utilizzo della CPU per i tuoi utenti? Cosa traduce il picco del pool di connessioni al database in termini di disponibilità del servizio o di prestazioni? È qui che gli Obiettivi di Livello di Servizio (SLO) diventano incredibilmente potenti, anche se non sei un vero SRE. Ti danno un obiettivo, e tu avvisi quando sei in pericolo di mancargli.
Diciamo che hai un SLO per la tua API principale: il 99,9% delle richieste dovrebbe completarsi entro 500 ms in un intervallo di 5 minuti. Non avvisi solo per alta CPU. Avvisi quando il tasso di errore aumenta o la tua latenza supera costantemente quella soglia di 500 ms. La CPU potrebbe essere un fattore contribuente, ma l’impatto sui tuoi utenti è ciò che ti interessa veramente.
Ecco un esempio semplificato di come potresti definire un avviso basato su un SLO per una fittizia API di e-commerce, magari utilizzando Prometheus e Alertmanager:
groups:
- name: api-slos
rules:
- alert: HighAPILatency
expr: |
(
sum(rate(http_request_duration_seconds_bucket{le="0.5", job="ecomm-api"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="ecomm-api"}[5m]))
) < 0.999
for: 5m
labels:
severity: critical
annotations:
summary: "La latenza dell'API di e-commerce sta superando l'SLO"
description: "Meno del 99,9% delle richieste API vengono completate entro 500 ms negli ultimi 5 minuti. Questo sta impattando l'esperienza utente."
runbook: "https://your-runbook-url/api-latency-troubleshooting.md"
Questo avviso non sta semplicemente dicendo "qualcosa è lento." Sta dicendo "la tua API sta fallendo il suo obiettivo di performance." È molto più significativo.
Il problema del "vicino rumoroso": raggruppamento e deduplicazione
Un'altra fonte comune di affaticamento da avvisi è il problema del "vicino rumoroso". Una causa radice può attivare una cascata di avvisi correlati. Il tuo database va giù? All'improvviso, ogni servizio che si connette ad esso inizia a urlare per errori di connessione. Invece di ricevere un avviso riguardo al database, ricevi venti riguardo ai servizi a valle. È qui che entrano in gioco raggruppamento e deduplicazione intelligenti.
La maggior parte dei moderni sistemi di gestione degli avvisi (pensa a PagerDuty, Opsgenie, VictorOps, e persino sofisticati set-up di Alertmanager) ha la capacità di raggruppare gli avvisi basati su attributi comuni. Se più avvisi arrivano con lo stesso host, servizio o modello di messaggio di errore, possono essere consolidati in un singolo incidente. Questo riduce notevolmente il rumore.
Diciamo che hai più microservizi, e tutti dipendono da una coda di messaggi condivisa. Se la coda dei messaggi va giù, ogni microservizio probabilmente riporterà "impossibile connettersi alla coda dei messaggi." Invece di avvisi individuali, vuoi un incidente riguardo alla coda dei messaggi che è giù. Questo comporta spesso la definizione di regole di correlazione. Ad esempio, in un sistema più avanzato, potresti impostare una regola che dice: "Se appaiono più di 3 avvisi con 'errore di connessione alla coda dei messaggi' entro 1 minuto, crea un incidente intitolato 'Coda dei Messaggi Irraggiungibile'."
Esempio: Routing semplice di Alertmanager per problemi specifici del servizio
Anche se la correlazione completa è complessa, anche un routing semplice aiuta. Ecco un frammento che mostra come Alertmanager può instradare gli avvisi basati su un'etichetta `service`, assicurando che gli avvisi per un servizio non inondino il canale per un altro, e potenzialmente raggruppandoli se raggiungono lo stesso ricevitore:
route:
receiver: 'default-receiver'
group_by: ['alertname', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
routes:
- match:
service: 'payment-gateway'
receiver: 'payment-gateway-team'
group_by: ['alertname'] # Raggruppa gli avvisi del gateway di pagamento in modo più aggressivo
- match:
service: 'user-auth'
receiver: 'user-auth-team'
Questa configurazione raggruppa gli avvisi per `alertname` e `service` per il default, ma specificamente per il servizio `payment-gateway`, raggruppa solo per `alertname`, indicando che se arrivano più tipi di avvisi per il gateway di pagamento, vanno comunque allo stesso team e vengono raggruppati insieme, riducendo il numero di notifiche individuali.
Elemento umano: Runbook e risoluzione
Un avviso senza un chiaro percorso verso la risoluzione è solo un reclamo. È qui che entrano in gioco i runbook. Ogni avviso critico dovrebbe avere un runbook associato - un insieme di passaggi documentati per diagnosticare e idealmente risolvere il problema. Non deve essere un romanzo di più pagine; anche alcuni punti elenco e collegamenti a cruscotti o registri pertinenti possono fare una grande differenza.
Pensa al mio incidente con il pool di connessioni al database delle 3 del mattino. Se quell'avviso avesse incluso una nota che dice “Se ciò accade tra le 2 e le 4 del mattino, controlla i lavori di backup attivi. Comportamento previsto”, sarei tornato subito a dormire. Il contesto e le istruzioni di risoluzione sono vitali per ridurre il tempo medio di recupero (MTTR) e, crucialmente, ridurre lo stress da reperibilità.
Mi piace pensarlo in questo modo: un avviso è una domanda. Un buon runbook è la risposta. Se il tuo avviso chiede “Cosa sta succedendo?”, il tuo runbook dovrebbe rispondere “Ecco cosa sta succedendo, e ecco cosa devi fare al riguardo.”
Indicazioni pratiche: Riappropriati della tua sanità mentale
Quindi, da dove iniziare se il tuo sistema di avviso è un disastro? Ecco alcuni passi pratici:
- Audita i tuoi avvisi attuali: Rivedi ogni singolo avviso che hai. Per ciascuno, chiediti:
- È azionabile? Dice a qualcuno di fare qualcosa di specifico?
- È unico? Potrebbe essere raggruppato con un altro avviso?
- Ha un runbook o chiare istruzioni per la risoluzione?
- Ha mai generato falsi avvisi? Con quale frequenza?
- Sta avvisando su sintomi o su impatti reali (violazioni dell'SLO)?
Sii spietato. Se un avviso non supera questi test, disattivalo o perfezionalo.
- Concentrati su avvisi basati su SLO: Cambia il tuo modo di pensare da metriche puramente infrastrutturali a indicatori di livello di servizio. Cosa conta davvero per i tuoi utenti? Avvisa quando questi sono in pericolo.
- Implementa raggruppamento intelligente e deduplicazione: Configura il tuo sistema di gestione degli avvisi per consolidare avvisi correlati in singoli incidenti. Questo è un cambiamento fondamentale per ridurre il rumore.
- Richiedi runbook per avvisi critici: Rendi obbligatorio che ogni avviso critico creato debba avere un runbook associato, anche uno semplice. Rivedi e aggiorna questi regolarmente.
- Condurre post-mortem per falsi allarmi: Ogni volta che ricevi un falso avviso, trattalo come un incidente reale. Fai un mini-post-mortem. Perché è scattato? Come possiamo prevenire che si ripeta? Era un problema di sintonizzazione? Manca il contesto?
- Rivedi regolarmente le soglie di avviso: I sistemi evolvono. Quello che era una soglia critica sei mesi fa potrebbe essere un comportamento normale oggi. Dedica del tempo trimestralmente per rivedere e regolare le soglie di avviso in base al comportamento attuale del sistema.
- Politiche di escalation: Avere percorsi di escalation chiari. Non ogni avviso deve svegliare qualcuno alle 3 del mattino. Classifica i tuoi avvisi per gravità e assicurati che le persone giuste vengano avvisate al momento giusto.
Avvisare non riguarda semplicemente impostare un monitor e premere "invia". È un’arte. Richiede un continuo affinamento, una profonda comprensione del tuo sistema e empatia per la povera anima che viene svegliata da quel pager. Essendo più intenzionali su cosa avvisiamo, come raggruppiamo quegli avvisi e il contesto che forniamo, possiamo passare da un'epidemia di affaticamento da avvisi a un sistema che ci permette davvero di mantenere i nostri servizi sani e i nostri utenti felici.
Ecco tutto per oggi. Andate, auditate quegli avvisi e riappropriatevi del vostro sonno. Ve lo siete guadagnati.
🕒 Published: