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. Ora, so cosa state pensando – “Allerta? Abbiamo già le allerte, Chris. Suonano. A volte.” Ma questo è precisamente il problema, vero?
Siamo nel 2026. Siamo oltre il punto in cui abbiamo solo allerte. Abbiamo bisogno di allerte efficaci. Allerete che ci dicano qualcosa di utile, non solo che un server da qualche parte si sente un po’ strano. Perché diciamolo chiaramente, un’allerta che viene ignorata è peggio di nessuna allerta. È un classico scenario del “ragazzo che gridava al lupo”, ma invece dei lupi, è un sistema critico che va giù mentre stai fissando 30 notifiche Slack non lette.
Il mio particolare cruccio di questi giorni? L’enorme volume di allerte “rumorose” che soffocano le vere emergenze. Ci siamo passati tutti. Configuri un nuovo servizio, pianifichi meticolosamente il tuo monitoraggio, e poi BAM! La tua inbox è un deserto di picchi della CPU, avvisi di memoria e allerte di spazio su disco che si risolvono da sole cinque minuti dopo. Prima che tu te ne accorga, stai premendo ‘Segna tutto come letto’ con l’efficienza di un gamer esperto che preme i pulsanti.
Quindi, oggi voglio parlare di come possiamo rendere le nostre allerte più intelligenti, più contestuali e, in ultima analisi, più fattibili. Non si tratta solo di ridurre il rumore; si tratta di ricostruire la fiducia nei nostri sistemi di monitoraggio. Si tratta di tornare a quella sensazione di “Oh cavolo, un’allerta! È meglio che controlli questo,” invece di “Ugh, un’altra.”
L’epidemia da affaticamento da allerta: le mie cicatrici di battaglia
Ricordo distintamente un progetto di qualche anno fa – una configurazione di microservizi piuttosto complessa per un cliente nel settore e-commerce. Immaginate centinaia di servizi, tutti che comunicano tra loro, tutti con le proprie piccole peculiarità. Avevamo monitoraggio ovunque, che sulla carta sembrava fantastico. In pratica? È stato un incubo.
Ogni distribuzione, ogni piccolo intoppo, ogni lieve aumento della latenza di rete innescava una cascata di allerte. La nostra rotazione di reperibilità era un pasticcio. Gli ingegneri erano esausti, costantemente a caccia di fantasmi. Personalmente, ho trascorso un intero sabato a fare debug di ciò che si è rivelato essere una scheda di rete difettosa su un server di sviluppo non critico che in qualche modo aveva ancora l’allerta a livello di produzione abilitata. Mia moglie era entusiasta, come potete immaginare.
Quell’esperienza mi ha insegnato una lezione dura: più allerte non equivalgono a più visibilità. Spesso significa 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 operare con precisione sul nostro sistema di allerte. Comprendere ciò che contava davvero e ciò che era solo rumore ambientale.
Oltre le soglie: allerte contestuali per la vittoria
Il tipo di allerta più comune, e arguibilmente il maggiore contributore all’affaticamento, è l’allerta con soglia semplice. Utilizzo della CPU oltre l’80%? Allerta! Spazio su disco sotto il 10%? Allerta! Anche se hanno il loro posto, spesso mancano di contesto. È negativo un utilizzo della CPU dell’80% se dura solo due minuti durante un processo batch programmato? Probabilmente no. È un problema avere il 10% di spazio su disco se è su un volume di lavoro temporaneo che si autopulisce ogni ora? Di nuovo, probabilmente no.
È qui che dobbiamo iniziare a pensare all’alerting contestuale. Si tratta di combinare più segnali e comprendere lo stato del tuo sistema, non solo metriche individuali.
1. Linee di base e rilevamento delle anomalie
Invece di soglie statiche, considera linee di base dinamiche. Cosa è “normale” per il tuo sistema durante ore o giorni specifici? Esistono strumenti ora in grado di apprendere questi schemi e avvisarti solo quando il comportamento si discosta 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 è 50ms durante le ore di punta e improvvisamente sale a 500ms per più di 5 minuti, quella è un’allerta. Ma se brevemente raggiunge 100ms durante una distribuzione e torna rapidamente alla normalità, quello è solo rumore.
2. Allerete correlate: il potere di E
Questo è il mio preferito assoluto per ridurre il rumore. Invece di avvisare basandosi su una singola metrica, combinale. Un’allerta non dovrebbe attivarsi a meno che non siano soddisfatte più condizioni, suggerendo un vero problema.
Supponiamo che tu abbia un server web. Singolarmente:
- 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 TUTTE queste cose accadono simultaneamente per più di 60 secondi? Adesso stai parlando di un vero problema. Il tuo server web sta probabilmente lottando per servire richieste legittime.
Ecco un esempio semplificato di come potresti configurarlo in un sistema di monitoraggio come Prometheus con Alertmanager, o anche in uno script personalizzato:
# Regola di allerta 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 errori"
description: "CPU, memoria e tassi di errore sono tutti elevati su {{ $labels.instance }}. È necessaria un'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 rispetto a una qualsiasi di quelle metriche da sola.
3. Allerete basate sugli obiettivi di livello di servizio (SLO)
Se sei serio riguardo all’affidabilità, stai probabilmente pensando agli SLO. Questi sono obiettivi concreti e misurabili per le prestazioni del tuo servizio. Invece di attivare allerte basate direttamente su metriche dell’infrastruttura sottostante, avvisa 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 200ms in un periodo di 7 giorni,” puoi impostare un’allerta che si attiva quando il tuo attuale budget di errore viene consumato troppo rapidamente. Ciò ti dice non solo che qualcosa è lento, ma che i tuoi clienti stanno subendo l’impatto e stai compromettendo il tuo obiettivo di affidabilità.
Questo è un approccio più maturo al monitoring perché si allinea direttamente all’impatto sul business. Non stai semplicemente riparando un server; stai proteggendo la reputazione del tuo servizio e la soddisfazione dei clienti.
Un modo semplice per pensare a questo è “tasso di consumo del budget di errore.” Se il tuo servizio ha un budget di errore (ad esempio, lo 0.1% delle richieste può fallire), e all’improvviso stai fallendo all’0.5% per un periodo prolungato, stai bruciando il tuo budget molto più velocemente del previsto. Un’allerta su questo tasso di consumo ti dà il tempo di reagire prima di violare effettivamente il tuo SLO per il mese.
# Allerta semplificata sul tasso di consumo dell'SLO (concettuale, dipende dal sistema di monitoraggio)
# Allerta 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) # tasso di errore consentito dello 0.1%, moltiplicato per un fattore di consumo (10x)
for: 5m
labels:
severity: warning
annotations:
summary: "Il servizio {{ $labels.service }} sta consumando rapidamente il budget di errore."
description: "Il tasso di errore attuale è significativamente superiore a quanto consentito dall'SLO. Indaga sulle recenti distribuzioni o su problemi upstream."
Questo tipo di allerta ti fornisce un avviso anticipato che stai andando verso una violazione, invece di dirti semplicemente quando l’hai già raggiunta.
Osservazioni pratiche per un alerting più intelligente
Quindi, come possiamo passare dal nostro attuale stato di affaticamento da allerta a un sistema di allerta più solido e che ispira fiducia? Ecco il mio piano d’azione:
- Audit delle tue allerte esistenti: Questo è il primo passo. Passa in rassegna ogni allerta che hai. Per ciascuna, chiediti:
- Quale problema indica questa allerta?
- Qual è il tempo di risoluzione previsto?
- Chi è responsabile di agire su di essa?
- Cosa succede se questa allerta viene ignorata? (Se nulla, cancellala.)
Sii spietato. Se un’allerta si attiva frequentemente senza richiedere azione, è un candidato per modifica o cancellazione.
- Prioritizza in base all’impatto: Non tutte le allerte sono create uguali. Usa livelli di gravità (critico, avviso, informazione) e assicurati che i tuoi canali di notifica lo riflettano. Le allerte critiche dovrebbero far suonare qualcuno. Le avvisi potrebbero andare in un canale meno intrusivo come un canale Slack dedicato o un’email. Le allerte informative? Probabilmente solo registri.
- Abbraccia la correlazione: Cerca opportunità per combinare più metriche in un’unica allerta più significativa. Se il tuo server dell’app è lento E il database mostra un alto I/O del disco, quella è un’unica allerta critica, non due avvisi separati.
- Utilizza soglie dinamiche o rilevamento delle anomalie: Laddove le soglie statiche ti deludono, esplora strumenti che possono apprendere il comportamento normale e avvisarti solo sulle deviazioni. Molte piattaforme di monitoraggio moderne offrono questo prontamente o tramite integrazioni.
- Concentrati sugli SLO, non solo sull’infrastruttura: Cambia il tuo atteggiamento da “il server è sano?” a “il servizio sta mantenendo la sua promessa agli utenti?” Le allerte basate sugli SLO forniscono un’analisi diretta dell’esperienza del cliente.
- Fai esercitazioni e testa le tue allerte: Non aspettare un incidente di produzione per scoprire che le tue allerte sono rotte o mal configurate. Pianifica regolari “esercitazioni antincendio” in cui inneschi intenzionalmente allerte e ti assicuri che si comportino come previsto. Vanno alle persone giuste? Il messaggio è chiaro?
- Documenta le tue allerte: Per ogni allerta, documenta cosa significa, perché è importante e i passaggi iniziali per la risoluzione dei problemi. Questo dà al tuo team di reperibilità l’abilità di reagire più velocemente e in modo più efficace.
Questo non è un rimedio una tantum. Costruire una cultura sana di allerta è un processo continuo. Richiede un affinamento continuo, ascoltando i tuoi team di reperibilità, e la volontà di adattarsi. Ma ti prometto che investire in allerte più intelligenti e contestuali darà risultati in termini di riduzione dell’affaticamento, risoluzione più rapida degli incidenti e, in ultima analisi, servizi più affidabili per i tuoi utenti.
Fermiamoci di gridare al lupo e iniziamo a inviare segnali chiari e fattibili. Il tuo futuro io (e il tuo team di reperibilità) ti ringrazierà.
🕒 Published: