Va bene, famiglia agntlog! Chris Wade qui, e oggi ci tuffiamo a capofitto in qualcosa che mi frulla in testa ultimamente: il modesto (o non così modesto) alert. So cosa state pensando: “Alert? Abbiamo alert, Chris. Si attivano. A volte.” Ma questo è esattamente il problema, vero?
È il 2026. Siamo oltre il punto di avere solo alert. Abbiamo bisogno di alert efficaci. Alert che ci dicano qualcosa di utile, non solo che un server da qualche parte si sente un po’ affaticato. Perché diciamocelo, un alert che viene ignorato è peggio di nessun alert. È uno scenario da ragazzo che ha gridato al lupo, ma invece dei lupi, è un sistema critico che va giù mentre stai fissando 30 notifiche di Slack non lette.
La mia particolare croce in questi giorni? Il numero enorme di alert “rumorosi” che oscurano le vere emergenze. Ci siamo passati tutti. Imposti un nuovo servizio, configuri meticolosamente il tuo monitoraggio, e poi BAM! La tua casella di posta è un deserto di picchi di CPU, avvisi di memoria e alert di spazio su disco che si risolvono da soli cinque minuti dopo. Prima che tu te ne accorga, stai cliccando su ‘Segna tutto come letto’ con l’efficienza di un giocatore esperto che preme pulsanti.
Quindi, oggi voglio parlare di come possiamo rendere i nostri alert più intelligenti, più contestuali e, in definitiva, più azionabili. Non si tratta solo di ridurre il rumore; si tratta di ricostruire fiducia nei nostri sistemi di monitoraggio. Si tratta di tornare a quella sensazione di “Oh caspita, un alert! Meglio che controlli questo,” invece di “Uff, un altro.”
L’epidemia della Fatica da Alert: Le mie cicatrici personali
Ricordo distintamente un progetto di qualche anno fa: un’installazione di microservizi piuttosto complessa per un cliente nel settore e-commerce. Pensate a centinaia di servizi, tutti che comunicano tra loro, tutti con le loro piccole peculiarità. Avevamo il monitoraggio ovunque, che sulla carta sembrava fantastico. In pratica? Era un incubo.
Ogni distribuzione, ogni piccolo intoppo, ogni leggero aumento della latenza di rete avrebbe attivato una cascata di alert. Il nostro turno di reperibilità era un disastro. Gli ingegneri erano esauriti, costantemente a caccia di fantasmi. Io, personalmente, ho trascorso un intero sabato a fare debug di quello che si è rivelato essere una scheda di rete difettosa su un server di sviluppo non critico che nel frattempo aveva ancora abilitato il monitoraggio di livello produzione. Mia moglie era entusiasta, come puoi immaginare.
Quell’esperienza mi ha insegnato una lezione dura: più alert non equivalgono a maggiore visibilità. Spesso significano meno. Quando tutto è urgente, nulla lo è. Ci eravamo effettivamente desensibilizzati ai segnali che avevamo messo in atto per proteggere i nostri sistemi.
La soluzione non era disattivare il monitoraggio. Era affinare la nostra segnalazione. Comprendere cosa contava davvero e cosa era solo chiacchiericcio ambientale.
Oltre le Soglie: Alert Contestuali per la Vittoria
Il tipo di alert più comune, e probabilmente il maggior contributore alla fatica, è l’alert semplice basato su soglie. Utilizzo della CPU oltre l’80%? Alert! Spazio su disco sotto il 10%? Alert! Anche se hanno il loro posto, spesso mancano di contesto. È davvero cattivo un utilizzo della CPU all’80% se dura solo due minuti durante un job batch programmato? Probabilmente no. È davvero cattivo un 10% di spazio su disco se è su un volume temporaneo che si auto-pulisce ogni ora? Di nuovo, probabilmente no.
È qui che dobbiamo iniziare a pensare a alerting contestuale. Si tratta di combinare più segnali e comprendere lo stato del tuo sistema, non solo metriche individuali.
1. Baseline e Rilevamento delle Anomalie
Invece di soglie statiche, considera baseline dinamiche. Qual è il “normale” per il tuo sistema durante determinate ore o giorni? Ora ci sono strumenti che possono apprendere questi modelli e avvisarti solo quando il comportamento devia significativamente dalla norma. Questo è particolarmente potente per cose come la latenza delle richieste o i tassi di errore, che possono fluttuare naturalmente durante la giornata.
Ad esempio, se il tuo tempo medio di risposta dell’API è di 50 ms durante le ore di picco e improvvisamente sale a 500 ms per più di 5 minuti, quello è un alert. Ma se colpisce brevemente 100 ms durante una distribuzione e torna rapidamente alla normalità, quello è solo rumore.
2. Alert Correlati: Il Potere di AND
Questo è il mio preferito assoluto per ridurre il rumore. Invece di avvisare su una singola metrica, combinale. Un alert non dovrebbe attivarsi a meno che non siano soddisfatte più condizioni, suggerendo un problema reale.
Diciamo che hai un server web. Individualmente:
- Utilizzo della CPU > 80%? Forse va bene.
- Utilizzo della memoria > 90%? Forse va bene.
- Tasso di errore > 5%? Forse è una richiesta client errata.
Ma cosa succede se TUTTI questi eventi si verificano simultaneamente per più di 60 secondi? Ora stai parlando di un vero problema. Il tuo server web sta probabilmente lottando per servire richieste legittime.
Ecco un esempio semplificato di come potresti configurare questo in un sistema di monitoraggio come Prometheus con Alertmanager, o anche in uno script personalizzato:
# Regola di Alerting di Prometheus (YAML)
groups:
- name: webserver-issues
rules:
- alert: HighLoadAndErrors
expr: |
(node_cpu_usage_percentage{job="webserver"} > 80)
and
(node_memory_usage_percentage{job="webserver"} > 90)
and
(sum(rate(http_requests_total{job="webserver", status!~"2xx|3xx"}[5m]))
/ sum(rate(http_requests_total{job="webserver"}[5m]))) > 0.05
for: 1m
labels:
severity: critical
annotations:
summary: "Il server web {{ $labels.instance }} sta vivendo un carico elevato e degli errori"
description: "CPU, memoria e tassi di errore sono tutti elevati su {{ $labels.instance }}. Richiesta di indagine immediata."
Questa regola non si attiverà a meno che tutte e tre le condizioni non siano soddisfatte per almeno un minuto. È un segnale molto più forte di qualsiasi di quelle metriche da sole.
3. Alert Basati su Obiettivi di Livello Servizio (SLO)
Se sei serio riguardo all’affidabilità, probabilmente stai pensando agli SLO. Questi sono obiettivi concreti e misurabili per le prestazioni del tuo servizio. Invece di attivare alert su metriche di infrastruttura sottostanti direttamente, attiva quando il tuo servizio è a rischio di violare il suo SLO.
Ad esempio, se il tuo SLO è “il 99,9% delle richieste deve completarsi entro 200 ms in un periodo di 7 giorni,” puoi impostare un alert che si attiva quando il tuo attuale budget di errore viene consumato troppo rapidamente. Questo non ti dice solo che qualcosa è lento, ma che i tuoi clienti stanno avvertendo l’impatto e che stai compromettendo il tuo obiettivo di affidabilità.
Questo è un approccio più maturo all’alerting perché si allinea direttamente con l’impatto aziendale. Non stai solo riparando un server; stai proteggendo la reputazione del tuo servizio e la soddisfazione del cliente.
Un modo semplice per pensare a questo è “tasso di combustione del budget di errore.” Se il tuo servizio ha un budget di errore (ad es., lo 0,1% delle richieste può fallire), e improvvisamente stai fallendo allo 0,5% per un periodo prolungato, quello sta bruciando il tuo budget molto più rapidamente del previsto. Un alert su questo tasso di combustione ti dà il tempo di reagire prima di superare effettivamente il tuo SLO per il mese.
# Alert semplificato sul Tasso di Combustione SLO (concettuale, dipende dal sistema di monitoraggio)
# Alert se il tasso di errore di 1 ora è 10 volte superiore a quello consentito dall'SLO settimanale
alert: SLOBurnRateHigh
expr: |
sum(rate(my_service_errors_total{}[1h])) / sum(rate(my_service_requests_total{}[1h]))
>
(0.001 * 10) # 0.1% di tasso di errore consentito, moltiplicato per un fattore di combustione (10x)
for: 5m
labels:
severity: warning
annotations:
summary: "Il servizio {{ $labels.service }} sta bruciando rapidamente il budget di errore."
description: "Il tasso di errore attuale è significativamente più alto di quanto consentito dall'SLO. Indaga su recenti distribuzioni o problemi upstream."
Questo tipo di alert ti dà un avviso precoce che stai andando verso una violazione, piuttosto che semplicemente dirti quando l’hai già raggiunta.
Indicazioni Pragmatiche per un Alerting più Intelligente
Quindi, come facciamo a passare dal nostro stato attuale di fatica da alert a un sistema di alerting più efficiente, che ispira fiducia? Ecco il mio piano d’azione:
- Audita i tuoi Alert Esistenti: Questo è il primo passo. Esamina ogni alert che hai. Per ciascuno, chiediti:
- Quale problema indica questo alert?
- Qual è il tempo di risoluzione previsto?
- Chi è responsabile per agire su di esso?
- Cosa succede se questo alert viene ignorato? (Se nulla, cancellalo.)
Sii spietato. Se un alert si attiva frequentemente senza richiedere azione, è un candidato per modifica o cancellazione.
- Prioritizza in base all’Impatto: Non tutti gli alert sono creati uguali. Usa livelli di severità (critico, avviso, informativo) e assicurati che i tuoi canali di notifica lo riflettano. Gli alert critici dovrebbero allertare qualcuno. Gli avvisi potrebbero andare a un canale meno invasivo come un canale Slack dedicato o via email. Gli alert informativi? Probabilmente solo log.
- Abbraccia la Correlazione: Cerca opportunità per combinare più metriche in un alert unico e più significativo. Se il tuo server delle app è lento E il database mostra un elevato I/O su disco, quello è un alert critico, non due avvisi separati.
- Usa Soglie Dinamiche o Rilevamento delle Anomalie: Dove le soglie statiche ti deludono, esplora strumenti che possono apprendere i comportamenti normali e attivarsi solo su deviazioni. Molte piattaforme di monitoraggio moderne offrono questo di default o tramite integrazioni.
- Concentrati sugli SLO, Non Solo sull’Infrastruttura: Cambia la tua mentalità da “il server è sano?” a “il servizio sta mantenendo la sua promessa per gli utenti?” Gli alert basati sugli SLO forniscono una visione diretta dell’esperienza del cliente.
- Fai Esercitazioni e Testa i Tuoi Alert: Non aspettare un incidente in produzione per scoprire che i tuoi alert sono rotti o mal configurati. Pianifica regolari “esercitazioni antincendio” in cui attivi intenzionalmente alert e ti assicuri che si comportino come previsto. Vanno alle persone giuste? Il messaggio è chiaro?
- Documenta i Tuoi Alert: Per ogni alert, documenta cosa significa, perché è importante e i primi passi per il troubleshooting. Questo dà potere al tuo team di reperibilità di reagire più rapidamente ed efficacemente.
Questo non è un rimedio una tantum. Costruire una cultura di alerting sana è un processo continuo. Richiede affinamento continuo, ascolto dei tuoi team di reperibilità, e disponibilità ad adattarsi. Ma ti prometto che investire in alert più intelligenti e contestuali porterà benefici in termini di riduzione della fatica, risoluzione più rapida degli incidenti e, in ultima analisi, servizi più affidabili per i tuoi utenti.
Fermiamoci di gridare al lupo e cominciamo a inviare segnali chiari e azionabili. Il tuo futuro io (e il tuo team di reperibilità) te ne saranno grati.
🕒 Published: