Paessler, azienda specializzata nel monitoraggio di rete, ha alcuni consigli per ridurre il rumore di fondo causato da un numero eccessivo di allarmi.
Uno dei principali problemi che i team IT Enterprise, ovvero quelli di infrastrutture con più di 1000 dispositivi, si trovano ad affrontare, infatti, è il rumore di fondo determinato dall’alto numero di allarmi durante il monitoraggio. Ciò avviene quando si deve tenere sotto controllo l’infrastruttura, la rete, lo storage, i servizi cloud e altri elementi: tutto questo genera continue allerte e notifiche per guasti reali o incombenti.
Un numero eccessivo di allarmi rende – di fatto – difficile l’identificazione dei problemi seri, oltre a portare potenzialmente a ignorare alcune allerte e a perdersi quelle importanti.
Come evitare che la situazione vada fuori controllo
Prima di passare ai consigli, sempre per Paessler, è importante capire quali sono le cause del rumore di fondo e perché è pericoloso ignorarlo. Gli ambienti IT Enterprise sono complessi ed eterogenei, con migliaia di dispositivi e applicazioni di molti fornitori diversi. Generalmente ci si ritrova con una molteplicità di tool di monitoraggio, ognuno dei quali monitora diversi aspetti dell’infrastruttura e invia notifiche e allarmi per ogni dettaglio del loro ambito di monitoraggio. Essendoci così tanti allarmi da tanti tool diversi, risulta quasi impossibile assegnare ogni allarme al membro del team IT responsabile di quell’ambito. Tutti gli allarmi finiscono quindi in una cartella IT centrale facendo perdere la visione d’insieme.
Un altro problema è l’assegnazione della corretta importanza a un allarme. Ad esempio: ricevere un allarme da un server che sta esaurendo la memoria è utile quando si gestiscono 5 server ma se ci sono 5000 server, l’allarme non è di nessuna utilità. Occorre essere in grado di stabilire le priorità e concentrarsi sugli allarmi più importanti riguardanti problemi che possono avere gravi conseguenze.
Sempre per Paessler, un’altra caratteristica comune delle grandi infrastrutture è la presenza di reti distribuite, ovvero quando si utilizzano più data center in sedi diverse. Se le reti sono gestite da una postazione centrale, tutti gli allarmi vengono probabilmente inviati al team centrale e si crea il rischio che gli allarmi vadano fuori controllo.
Se gli allarmi sono troppi rischiano di diventare poco significativi o che gli indicatori importanti vengano perduti. Per questo è importante ridurre la quantità di allarmi grazie a una combinazione di attenta pianificazione strategica e del giusto tool di monitoraggio.
4 metodi suggeriti da Paessler per limitare il rumore di fondo
Utilizzare un unico strumento di monitoraggio
Consolidare il monitoraggio in un unico strumento anziché avere molteplici tool con diversi metodi di allerta, fa sì che in presenza di allarmi ci sarà solo una fonte da indagare per scoprire il problema. Inoltre, poiché i vari tool gestiscono allerte e notifiche in modo diverso, disporre di un unico strumento significa poter applicare sempre la stessa filosofia.
Fissare correttamente le soglie
Gli allarmi sono basati su valori soglia: quando un dispositivo supera una certa temperatura prestabilita o quando lo storage disponibile scende sotto un dato numero di gigabyte, scatta l’allarme. Una buona gestione del monitoraggio dipende quindi dall’avere stabilito soglie corrette. Se sono troppo basse si sarà inondati di allarmi, se troppo alte non si verrà avvisati dei problemi se non quando sarà troppo tardi. Sembra facile, ma quando si deve monitorare migliaia di dispositivi e applicazioni è necessario adottare una soluzione di monitoraggio che offra automazione e altri meccanismi come l’ereditarietà delle soglie per gruppi di dispositivi.
Definire i team di reazione e filtrare gli allarmi
Per definire i team di reazione lo strumento di monitoraggio deve essere dotato di funzionalità complete di gestione di ruoli e privilegi: questo permette di creare agevolmente ruoli e responsabilità per specifici team (o anche individui) e di filtrare gli allarmi di conseguenza. In questo modo si può stabilire di inviare le notifiche relative a quelle aree solamente ai team che devono esserne a conoscenza ed evitare inutili allarmi.
Definire gli allarmi di alto livello
Per Paessler non tutte le persone all’interno dell’organizzazione hanno necessità di sapere cosa succede dietro le quinte dell’infrastruttura. I team IT devono ovviamente saperlo, ma in generale i decisori, il management e gli stakeholder è sufficiente che vengano informati solo se si presentano problemi a livelli molto elevati.
Una valida strategia da adottare per “scremare” le informazioni, consiste nell’organizzare l’infrastruttura IT in servizi in funzione dei processi di business: il servizio email, il sistema di licensing, i processi di costruzione del software sono tutti servizi IT forniti da diversi “pezzi” connessi di hardware, software e connettività.
Per i servizi email, ad esempio, è necessario mappare le componenti mail server, storage server e connettività Internet dell’infrastruttura. Secondo Paessler, se si verifica un guasto di poca importanza su uno di questi componenti (ad esempio un mail server ridondante presenta problemi di performance), il servizio email in sé non è a rischio perché sono disponibili mail server di failover. In questo caso viene avvisato solo il team IT responsabile del servizio, non c’è bisogno di allertare il management. Se invece si verifica un problema critico (ad esempio un crash dello switch core attraverso cui passano tutte le mail) il servizio email è a rischio e l’allarme deve essere inviato al management o ad alcuni stakeholder.
Per facilitare il monitoraggio degli ambienti IT Enterprise, Paessler ha creato una guida (in inglese) disponibile gratuitamente QUI.
