Un buon monitoraggio IT dipende dalla sua precisione. Deve informarvi al momento giusto quando qualcosa non va. Tuttavia, analogamente alle statistiche, anche nel monitoraggio dobbiamo fare i conti con i falsi positivi e i falsi negativi.

Un falso positivo è uno strumento di monitoraggio che segnala un problema quando in realtà il sistema monitorato è perfettamente a posto. Potrebbe trattarsi di un server indicato come DOWN perché c'è stato un breve inconveniente nella connessione di rete, o di un breve picco nella larghezza di banda utilizzata da un dispositivo di rete che fa scattare un allarme critico, mentre 5 secondi dopo tutto è tornato alla normalità.

I falsi negativi si verificano quando il vostro sistema di monitoraggio non vi avvisa, anche se c'è davvero qualcosa che non va. Se il firewall è fuori uso, è bene che lo sappiate. Se il vostro sistema di monitoraggio, per qualche motivo, non vi avvisa di questo, potete mettervi nei guai molto rapidamente.

Come nel caso delle statistiche, non è possibile eliminare completamente gli errori nel monitoraggio, ma il problema è che quando si gestisce un'infrastruttura IT aziendale, il costo di un falso positivo e di un falso negativo può essere molto diverso. Un falso negativo potrebbe essere un sistema mission-critical non funzionante e non allertato. Un falso positivo potrebbe essere solo una notifica inutile che viene rapidamente cancellata dalla casella di posta.

Pertanto, quando i team IT Ops cercano di determinare il livello accettabile di falsi positivi rispetto al livello accettabile di falsi negativi, spesso ritengono più accettabili i falsi positivi. Si preferisce la cautela e la notifica, il che è del tutto comprensibile. La conseguenza, tuttavia, è che questi team vengono sommersi da avvisi senza senso, il che aumenta il rischio di trascurare un avviso critico.

In questo articolo vi illustrerò alcuni semplici modi per perfezionare le notifiche del vostro sistema di monitoraggio, in modo da non essere sommersi da avvisi e da ricevere solo quelli veramente rilevanti. Perché le notifiche saranno utili solo se non vengono prodotti falsi allarmi, o solo occasionalmente.

Sto lavorando con Checkmk, quindi i miei suggerimenti faranno uso delle funzioni disponibili in Checkmk. Alcune di esse possono essere o meno disponibili nel vostro strumento di monitoraggio preferito.

1. Non inviare alert. O almeno, non durante la configurazione.

In Checkmk, le notifiche sono facoltative. Il sistema di monitoraggio può essere utilizzato in modo efficiente anche senza di esse. Alcune grandi organizzazioni hanno una sorta di pannello di controllo in cui un team operativo monitora costantemente l'interfaccia di Checkmk, e quindi le notifiche aggiuntive non sono necessarie. Si tratta in genere di utenti che non possono rischiare alcun downtime dell'IT, come ad esempio una borsa valori. Utilizzano le dashboard dei problemi in Checkmk per vedere immediatamente il problema e i suoi dettagli. Dato che gli elenchi sono per lo più vuoti, quando appare qualcosa di "rosso" su una grande dashboard, diventa molto evidente.

Ma, a mio parere, quella appena descritta è più un'eccezione. La maggior parte delle persone utilizza un modo per notificare i team operativi e di sysadmin, che sia tramite e-mail, SMS o plugin di notifica per strumenti ITSM come ServiceNow, PagerDuty o Splunk OnCall.

Una versione declinata di questo consiglio è: non inviare avvisi quando si sta ancora configurando il monitoraggio per la prima volta. Avviate il monitoraggio, risolvete i problemi rilevati, quindi attivate le notifiche passo dopo passo. In questo modo, eviterete di generare un gran numero di avvisi che potrebbero sovraccaricare il vostro team. Prima di impostare gli avvisi nel nuovo strumento di monitoraggio, portate la vostra infrastruttura in una forma corretta.

2. Dai tempo al tempo

Se avete deciso di non seguire la strada dell'"assenza di notifiche" del punto precedente, dovete assicurarvi che le vostre notifiche siano regolate in modo da avvisare solo in caso di problemi reali.

La prima cosa da fare nei confronti del vostro sistema di monitoraggio è: Dargli tempo.

Alcuni sistemi producono errori sporadici e di breve durata. Di certo dovreste indagare ed eliminare la causa di questi problemi sporadici, ma approfondirli tutti mentre si verificano potrebbe essere inutile.

È possibile ridurre gli allarmi provenienti da sistemi di questo tipo in due modi: Si può semplicemente ritardare l'invio delle notifiche solo dopo un determinato periodo di tempo. E solo se nel frattempo lo stato del sistema non è cambiato in OK. In alternativa, è possibile utilizzare un Numero massimo di tentativi di controllo per il servizio per indicare al monitoraggio di inviare una notifica solo se il problema persiste per diversi intervalli di check (l'intervallo predefinito di Checkmk è di 1 minuto, ma si può configurare diversamente).

Le due opzioni differiscono leggermente nel modo in cui trattano il sistema monitorato, ma approfondire questo ci porterebbe troppo nel mondo di Checkmk. Il concetto importante è: dando al sistema un po’ di tempo per “riprendersi”, si può evitare una valanga di notifiche inutili.

Questo metodo funziona bene anche per i sistemi "self-healing" che dovrebbero riprendersi da soli; non si vorrebbe di certo ricevere notifiche in casi di veloce "auto-guarigione".

Naturalmente, quanto detto sopra non vale per sistemi che sono così mission-critical da non potersi permettere alcun tempo di inattività, e che richiedono reazioni immediate. Ad esempio, un hedge-fund che monitora il collegamento di rete a un mercato dei derivati non può operare se questo si blocca. Ogni secondo di inattività potrebbe costare caro.

3. In media, non abbiamo problemi

Le notifiche sono spesso attivate da valori di soglia sulle metriche di utilizzo (ad esempio, l'utilizzo della CPU) che potrebbero superare la soglia solo per un breve periodo. In linea di massima, questi brevi picchi non costituiscono un problema e non dovrebbero causare immediatamente l'invio di notifiche da parte del sistema di monitoraggio.

Per questo motivo, molti plug-in di controllo dispongono di un'opzione di configurazione che consente di calcolare la media delle metriche su un periodo più lungo (ad esempio, 15 minuti) prima di applicare le soglie di allarme. Utilizzando questa opzione, i picchi temporanei vengono ignorati e la metrica viene prima calcolata sulla media del periodo di tempo definito e solo successivamente i valori di soglia vengono applicati a questo valore medio.

4. Tali genitori, tali figli

Immaginate il seguente scenario: Si sta monitorando un data center remoto. In quel data center ci sono centinaia di server che funzionano bene e che vengono monitorati dal sistema di monitoraggio. Tuttavia, la connessione a questi server passa attraverso lo switch centrale del data center. Se lo switch centrale si guasta, si scatena l'inferno. All'improvviso, centinaia di host non vengono più raggiunti dal sistema di monitoraggio e vengono indicati come DOWN. Centinaia di host DOWN significano un'ondata di centinaia di notifiche...

Ma in realtà tutti quei server stanno andando bene. È solo quell'unico switch core che fa i capricci. Quindi cosa fare?

È necessario comunicare al sistema di monitoraggio che tutti i server dipendono da quello switch principale. È possibile farlo in Checkmk utilizzando la funzione "parent-child-relationships". Dichiarando l'host A come 'figlio' di un altro host 'genitore', B, si comunica al sistema Checkmk che A dipende dall'host B. Checkmk sospende le notifiche per i figli se il genitore è inattivo e li contrassegna come UNREACH.

Nota: Un host figlio può avere più di un host genitore. Un host figlio diventa irraggiungibile solo quando tutti i suoi host genitori sono inattivi.

5. Evita gli avvisi su sistemi che dovrebbero essere inattivi

Possono esserci centinaia di motivi per cui un sistema dovrebbe essere inattivo. Alcuni sistemi potrebbero dover essere riavviati regolarmente, forse si sta facendo manutenzione o semplicemente non si ha bisogno di uno specifico sistema in certi momenti. Quello che non volete è che il vostro sistema di monitoraggio entri nel panico, avvisando chissà chi quando in un contesto come quello appena descritto, un sistema dovesse essere fuori uso.

A tal fine, è possibile utilizzare i tempi di inattività programmati. Durante i tempi di inattività programmati, Checkmk non emetterà alcun avviso per quel sistema, pur continuando a monitorarlo. È semplicissimo. È anche possibile programmare tempi di inattività ricorrenti se si utilizza un'edizione commerciale di Checkmk. Così, se si sa che un certo sistema viene riavviato ogni notte tra mezzanotte e le due del mattino, si può impostare un tempo di inattività ricorrente per quella finestra temporale e non ricevere mai una notifica errata quando l'host in questione è inattivo per un breve periodo durante quel periodo.

I tempi di inattività programmati funzionano per interi host, ma anche per singoli servizi. Ma perché inviare determinati servizi a downtime programmati? Più o meno per lo stesso motivo degli host: quando si sa che sta per succedere qualcosa che farebbe scattare una notifica non necessaria. Si vuole comunque che il monitoraggio tenga d'occhio l'host nel suo complesso, ma si prevede e si accetta che alcuni servizi possano andare in tilt e superare le soglie per qualche tempo. Un esempio potrebbe essere un CronJob notturno che sincronizza i dati da qualche parte, causando un picco di un servizio come l'I/O del disco. Ma se tutto torna alla normalità una volta terminata la sincronizzazione, non c'è bisogno di perderci il sonno.

Inoltre, è possibile estendere i tempi di inattività programmati anche ai 'figli' di un host 'genitore'.

Per concludere

Spero che questa breve panoramica vi abbia dato qualche idea sui modi più semplici per ridurre il numero di notifiche inutili che il vostro team operativo riceve dal sistema di monitoraggio. Molte delle funzioni che ho descritto non sono esclusive di Checkmk, ma sono disponibili anche in altri strumenti di monitoraggio. Ci sono molti altri modi, ma questo dovrebbe essere un buon punto di partenza.

La messa a punto degli avvisi è una delle attività più importanti, ma anche più gratificanti, quando si tratta di configurare il sistema di monitoraggio. L'impatto di una configurazione ben definita delle notifiche si farà sentire immediatamente.

Se volete saperne di più su come gestire le notifiche in Checkmk, date un'occhiata a questo articolo della documentazione o scrivete una domanda nel forum.