Un allarme è un messaggio a una persona, non una riga di log

Ogni piattaforma di monitoraggio sa rilevare un problema. La parte difficile è l'ultimo miglio: portare l'allarme giusto davanti a una persona che può agire, entro pochi secondi, senza seppellire quella persona sotto allarmi che non contano. Ecco come instradiamo gli allarmi in Zabbix, e come potete verificare se la vostra catena funziona davvero.

Rilevare costa poco, l'attenzione costa molto

La maggior parte delle configurazioni di monitoraggio non fallisce perché manca un problema. Fallisce perché nessuno legge ciò che produce. Gli alert via email finiscono in una cartella che si riempie più in fretta di quanto chiunque riesca a svuotarla. Le dashboard diventano rosse e restano rosse per settimane, finché il rosso non significa più nulla. L'ingegnere che alla fine se ne accorge di solito sta reagendo a un cliente, non al monitor.

Aggiungere altri controlli non risolve questo. Ciò che lo risolve è un design di instradamento che tratta l'attenzione di un ingegnere come la risorsa più scarsa che avete, e la spende solo per le cose che richiedono una persona adesso.

Decidete cosa può raggiungere una persona

Partite dalla severità, e siate rigorosi. Ogni trigger Zabbix porta una severità, da information fino a disaster. Noi instradiamo solo le due più alte, high e disaster, all'ingegnere reperibile, e ogni trigger a quel livello deve superare un test: se scatta di notte, qualcuno deve agire prima del mattino? Se la risposta onesta è no, è un warning. I warning stanno sulle dashboard e nella revisione quotidiana, non nella tasca di qualcuno.

In Zabbix quella decisione vive in due posti: le condizioni sull'action (la severità del trigger è maggiore o uguale a High) e il filtro di severità sul media dell'utente. Impostate entrambi, e fateli concordare. Un'action che corrisponde a tutto, combinata con un filtro sul media che ne scarta in silenzio la metà, è una configurazione su cui nessuno può ragionare alle tre di notte.

Poi sopprimete gli echi. Quando uno switch va giù, anche ogni host dietro di lui diventa irraggiungibile. Le dipendenze tra trigger dicono a Zabbix che gli allarmi degli host dipendono dall'allarme dello switch, così l'ingegnere riceve un allarme che indica la causa invece di quaranta che indicano i sintomi.

Consegnatelo dove l'ingegnere già si trova

I nostri allarmi escono da Zabbix attraverso un webhook verso un canale operativo dedicato in Mattermost, la chat in cui i nostri ingegneri lavorano tutto il giorno e che portano sul telefono di notte. La chat batte l'email per gli allarmi per ragioni pratiche. È dove le persone già guardano. Mostra chi ha visto il messaggio. E la conversazione sulla soluzione avviene nel thread sotto l'allarme, così il thread diventa il registro di cosa è stato fatto e quando.

Un buon messaggio di allarme porta abbastanza per agire senza aprire altri tre strumenti: l'host, il nome del trigger, la severità, il valore corrente, da quanto tempo è in quello stato, e un link diretto al grafico. Scrivete il template del messaggio una volta, con cura, e ogni allarme che invierete ne beneficerà.

Rendete visibile l'ownership

Un allarme che tre persone hanno visto e nessuno ha preso in carico è grave quanto uno che nessuno ha visto. L'acknowledgement chiude quel divario. Quando l'ingegnere reperibile riconosce un problema in Zabbix, con una breve nota, tutti gli altri vedono che è preso in carico, e la nota è la prima riga del registro. Se il vostro team ha una seconda linea, un passaggio di escalation sull'action (un'ulteriore notifica quando un problema ad alta severità è ancora senza acknowledgement dopo un numero prestabilito di minuti) trasforma «probabilmente qualcuno guarderà» in una regola.

I lavori pianificati meritano il trattamento opposto: un team che viene allertato dalla propria manutenzione impara a ignorare gli allarmi, e quell'abitudine non resta dentro la finestra di manutenzione.

Dimostrate che funziona

Dimostrate la catena dopo ogni modifica

Nulla di tutto questo conta finché non avete guardato un allarme reale percorrere tutta la strada. Dopo ogni modifica alla piattaforma di monitoraggio facciamo scattare un allarme vero e lo cronometriamo dal trigger al messaggio. Il nostro team di rete ha scritto esattamente come eseguire quel test, e come confermare che ogni dispositivo viene ancora ascoltato, in Testate il percorso dell'allarme, non la dashboard. Conservate i tempi che registrate. Se il numero cresce tra un test e l'altro, qualcosa nella catena sta rallentando, e lo avete scoperto da un test invece che da un'interruzione.

Tarate per host, non silenziate mai alla cieca

I template condivisi sono il luogo in cui nasce l'alarm fatigue. Un server di database gira legittimamente caldo, qualcuno alza la soglia di CPU nel template per farlo tacere, e ogni altro host del parco ha appena perso un allarme utile. Noi non modifichiamo mai un template condiviso per tarare una sola macchina. Le soglie che devono differire sono impostate come override di macro a livello di host, per esempio il valore proprio di quell'host di {$CPU.UTIL.CRIT}, così tarare una macchina non cambia mai gli allarmi di un'altra.

La stessa regola vale per spegnere i trigger. Un trigger che scatta di continuo vi sta dicendo qualcosa: o la soglia è sbagliata per quell'host, o l'host ha un problema reale. Disabilitarlo per far tornare verde il quadro rimuove l'unico testimone. Correggete la soglia su quell'host, o correggete l'host.

Sorvegliate il sorvegliante

Un monitor che si è fermato è peggio di nessun monitor, perché vi fidate del suo silenzio. Due controlli coprono la maggior parte del rischio. Dentro Zabbix, un trigger nodata su ogni agent, come nodata(/<host>/agent.ping,5m)=1, cattura un host che ha smesso di riferire, che è un guasto diverso e più silenzioso rispetto a un host che riferisce problemi. Fuori da Zabbix, qualcosa di indipendente deve accorgersi quando la piattaforma stessa tace: un heartbeat che il server invia a intervalli a un sistema separato, il quale solleva il proprio allarme quando l'heartbeat smette di arrivare.

Trattiamo inoltre la piattaforma di monitoraggio come produzione: retention del database applicata, e un audit dall'hardware su attraverso sistema operativo, database, daemon e percorso degli alert.

Una seconda opinione prima che l'ingegnere legga

Le regole filtrano prima il rumore noto, poi ogni allarme rimasto viene analizzato in tempo reale da modelli AI che girano sulle nostre GPU NVIDIA A100, dentro il nostro datacenter. L'analisi guarda l'allarme insieme agli eventi recenti, agli host correlati e ai pattern noti, e gli affianca una breve seconda opinione: cos'altro è cambiato nelle vicinanze, e cosa ha significato questo pattern in passato. Non decide nulla e non allerta nessuno. Risparmia all'ingegnere i primi minuti di ricognizione. Poiché i modelli girano sul nostro hardware, i dati di monitoraggio non lasciano mai la nostra rete e non vengono mai inviati a un servizio AI pubblico.

Se costruite qualcosa di simile, mantenete lo stesso confine. L'AI annota l'allarme. Una persona è proprietaria della decisione.

Controllate la vostra catena

Quali severità raggiungono una persona, e quella decisione è scritta?
Tutti possono vedere chi è proprietario di un allarme aperto?
Quando qualcuno ha fatto scattare per l'ultima volta un allarme di prova reale cronometrandolo da un capo all'altro?
Il guasto di uno switch arriva come un allarme o come quaranta?
Qualcuno ha tarato una soglia modificando un template condiviso?
Quanti trigger sono disabilitati in questo momento, e qualcuno sa perché?
Cosa vi dice che la piattaforma di monitoraggio stessa si è fermata?

Se desiderate un secondo paio di occhi su come i vostri allarmi raggiungono le vostre persone, siamo lieti di dare un'occhiata. Parla con un ingegnere

footer line: Pubblicato il 22 ottobre 2026. Tutte le note dal campo

Un allarme è un messaggio a una persona, non una riga in un log