Va bene, amici. Chris Wade qui, di nuovo nelle trincee digitali per agntlog.com. Oggi non stiamo solo esplorando un concetto; stiamo approfondendo qualcosa che, francamente, mi tiene sveglio la notte. Non in senso negativo, di solito. Più in un modo del tipo “e se mi fosse sfuggita quella cosa?”. Stiamo parlando di alerting, nello specifico, di come spesso ci sbagliamo e di come rimediare prima che ci costi più del semplice sonno.
La data attuale è 29 marzo 2026. E se sei come me, la tua inbox, Slack o qualunque piattaforma di comunicazione tu stia usando è probabilmente un accumulo straripante di notifiche. La maggior parte di esse sono inutili. E questo, amici miei, è l’angolo tempestivo su cui stiamo colpendo oggi. Siamo diventati così bravi a raccogliere dati, così abili a monitorare ogni piccola vibrazione nei nostri sistemi, che abbiamo completamente dimenticato l’obiettivo di un avviso: dirci quando qualcosa ha veramente bisogno della nostra attenzione, proprio ora.
L’epidemia di affaticamento da avvisi: la mia battaglia personale
Mettiamoci seri per un attimo. Il mio primo vero lavoro dopo l’università è stato in un piccolo team che gestiva una piattaforma SaaS piuttosto complessa. Eravamo giovani, ambiziosi e assolutamente convinti che più avvisi significasse più controllo. Oh, quanto eravamo ingenui. Ogni picco della CPU oltre il 70%, ogni allocazione di memoria che superava una certa soglia, ogni singolo errore HTTP 500 – tutto questo attivava un avviso. E questi non erano solo indicatori da dashboard; si trattava di chiamate PagerDuty, inondazioni di email e tempeste di canali Slack.
Ricordo un martedì mattina, intorno alle 3 di notte. Il mio telefono ha vibrato e si è buttato giù dal comodino. PagerDuty. Avviso critico. “Utilizzo del pool di connessione al database oltre l’80%.” Il mio cuore è saltato. Ho cercato il mio laptop, ho attivato la VPN ed ho iniziato a scavare. Si è scoperto che era un lavoro di backup notturno programmato che ha brevemente, per circa 15 minuti, aumentato l’utilizzo del pool di connessione. Era un comportamento completamente normale e previsto. Ma poiché non avevamo pensato al contesto, poiché non avevamo sintonizzato i nostri avvisi, ero lì a fissare uno schermo alle 3 di notte senza alcun valido motivo.
Quello è stato un momento cruciale per me. Non si trattava solo del mio sonno perduto; si trattava della desensibilizzazione che seguì. Dopo alcune settimane di questi falsi allarmi, gli avvisi critici genuini hanno iniziato a mescolarsi. Questo è l’affaticamento da avvisi. È subdolo. Trasforma il tuo sistema di monitoraggio altamente sintonizzato in rumore di fondo, e quando scoppia un vero incendio, sei meno propenso a notarlo, tanto meno a rispondere in modo efficace.
Oltre la soglia: cosa rende un buon avviso?
Quindi, se “più avvisi” non è la risposta, quale è? Per me, un buon avviso ha tre caratteristiche fondamentali:
- Immediato: Ti dice qualcosa su cui puoi effettivamente agire.
- Tempestivo: Ti colpisce quando conta, non troppo presto, non troppo tardi.
- Contestuale: Fornisce abbastanza informazioni per comprendere il problema senza un’ampia ricerca.
La maggior parte di noi è abbastanza brava nella parte “tempestiva”, grazie agli strumenti di monitoraggio moderni. Ma “immediato” e “contestuale” sono dove spesso falliamo. Impostiamo un avviso per “utilizzo CPU > 90% per 5 minuti.” Ok, immediato? Forse. Se significa un processo fuori controllo, certo. Ma cosa succede se è un lavoro batch che deve sfruttare al massimo la CPU per 10 minuti ogni giorno alle 13:00? È qui che entra in gioco il contesto.
Dai sintomi alla malattia: avvisare sull’impatto
Invece di avvisare solo sui metriche grezze, dobbiamo spostare il nostro pensiero per avvisare sull’impatto. Cosa significa un alto utilizzo della CPU per i tuoi utenti? Cosa significa quel picco nel pool di connessione al database in termini di disponibilità del servizio o prestazioni? Qui è dove gli Obiettivi di Livello di Servizio (SLO) diventano incredibilmente potenti, anche se non sei un SRE completo. Ti danno un obiettivo, e avvisi quando sei in pericolo di non raggiungere quell’obiettivo.
Immagina di avere un SLO per la tua API principale: il 99,9% delle richieste dovrebbe completarsi entro 500ms su una finestra di 5 minuti. Non avvisi solo per alta CPU. Avvisi quando il tuo tasso di errore sale o quando la tua latenza supera costantemente quella soglia di 500ms. La CPU potrebbe essere un fattore contribuente, ma l’impatto sui tuoi utenti è ciò che ti sta veramente a cuore.
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 500ms negli ultimi 5 minuti. Questo sta influenzando l'esperienza utente."
runbook: "https://your-runbook-url/api-latency-troubleshooting.md"
Questo avviso non sta solo dicendo "qualcosa è lento." Sta dicendo "la tua API sta fallendo il suo obiettivo di prestazioni." È 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ò innescare una cascata di avvisi correlati. Il tuo database va giù? Improvvisamente, ogni servizio che si connette a esso inizia a urlare per errori di connessione. Invece di ricevere un avviso sul database, ne ricevi venti sui servizi a valle. Qui entrano in gioco il raggruppamento intelligente e la deduplicazione.
La maggior parte dei moderni sistemi di gestione degli avvisi (pensa a PagerDuty, Opsgenie, VictorOps, anche a configurazioni più sofisticate di Alertmanager) hanno capacità di raggruppare 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 significativamente il rumore.
Diciamo che hai più microservizi, e tutti fanno affidamento su una coda di messaggi condivisa. Se la coda di messaggi va giù, ogni microservizio probabilmente riporterà "impossibile connettersi alla coda dei messaggi." Invece di avvisi individuali, vuoi un incidente riguardante la coda di messaggi che non è raggiungibile. Questo comporta spesso la definizione di regole di correlazione. Ad esempio, in un sistema più avanzato, potresti impostare una regola che dice: "Se più di 3 avvisi con 'errore di connessione alla coda dei messaggi' appaiono entro 1 minuto, crea un incidente intitolato 'Coda di Messaggi Non Raggiungibile'."
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 avvisi basati su un'etichetta `service`, assicurando che gli avvisi per un servizio non inondino il canale di un altro, e raggruppandoli potenzialmente 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 più aggressivamente gli avvisi del gateway di pagamento
- match:
service: 'user-auth'
receiver: 'user-auth-team'
Questa configurazione raggruppa gli avvisi per `alertname` e `service` per il predefinito, ma specificamente per il servizio `payment-gateway`, raggruppa solo per `alertname`, indicando che se arrivano più tipi di avvisi per il gateway di pagamento, essi vanno comunque allo stesso team e vengono raggruppati, riducendo il numero di notifiche individuali.
L'elemento umano: Runbook e rimedio
Un avviso senza un chiaro percorso di risoluzione è solo un reclamo. Qui entrano in gioco i runbook. Ogni avviso critico dovrebbe avere un runbook associato – un insieme documentato di passaggi per diagnosticare e idealmente risolvere il problema. Non deve essere un romanzo di più pagine; anche pochi punti elenco e link a dashboard o log pertinenti possono fare una grande differenza.
Pensa al mio incidente del pool di connessione del database alle 3 del mattino. Se quell'avviso avesse incluso una nota che diceva "Se questo 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 rimedio sono fondamentali per ridurre il tempo medio di recupero (MTTR) e, soprattutto, ridurre lo stress da chiamata in servizio.
Mi piace pensare 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."
Takeaway pratici: riconquista la tua sanità mentale
Quindi, da dove inizi se il tuo sistema di avviso è un caos? Ecco alcuni passi pratici:
- Audit dei tuoi avvisi attuali: Passa attraverso ogni singolo avviso che hai. Per ciascuno, chiediti:
- È immediato? Dice a qualcuno di fare qualcosa di specifico?
- È unico? Potrebbe essere raggruppato con un altro avviso?
- Ha un runbook o chiari passaggi di rimedio?
- Ha mai attivato falsamente? Quanto spesso?
- Sta avvisando su sintomi o su un impatto reale (violazioni dell'SLO)?
Sii spietato. Se un avviso non supera questi test, disabilitalo o perfezionalo.
- Concentrati sull'avviso basato su SLO: Sposta la tua mentalità da metriche puramente infrastrutturali a indicatori a livello di servizio. Cosa conta davvero per i tuoi utenti? Avvisa quando questi sono minacciati.
- Implementa raggruppamento e deduplicazione intelligente: Configura il tuo sistema di gestione degli avvisi per consolidare avvisi correlati in singoli incidenti. Questo è un punto di svolta per ridurre il rumore.
- Imponi runbook per avvisi critici: Rendi obbligatorio che ogni avviso critico creato debba avere un runbook associato, anche uno semplice. Rivedili e aggiornali regolarmente.
- Conduci post-mortem per falsi allarmi: Ogni volta che ricevi un falso avviso, trattalo come un vero incidente. Fai un mini-post-mortem. Perché è stato attivato? Come possiamo prevenire che si attivi di nuovo? È stata una questione di sintonizzazione? Un contesto mancante?
- Rivedi regolarmente le soglie degli avvisi: I sistemi evolvono. Ciò che era una soglia critica sei mesi fa potrebbe essere un comportamento normale oggi. Dedicati del tempo ogni trimestre per rivedere e regolare le soglie degli avvisi 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. Sistema i tuoi avvisi per severità e assicurati che le persone giuste siano notificate al momento giusto.
Avvisare non significa solo impostare un monitor e premere "invio". È un'arte. Richiede un continuo perfezionamento, 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 abilita davvero a mantenere i nostri servizi sani e i nostri utenti felici.
È tutto per me oggi. Avanti, controlla quegli avvisi e riconquista il tuo sonno. Te lo sei guadagnato.
🕒 Published: