La maggior parte delle organizzazioni sa che hanno bisogno del monitoraggio per garantire l’uptime del sito e mantenere in funzione la propria attività. Eppure, a causa di piccoli errori commessi dai loro sistemi di monitoraggio, molti siti soffrono di interruzioni e i clienti sono i primi a segnalarle. Gli errori di monitoraggio sono facili da commettere e facili da trascurare, ma le conseguenze possono essere dannose. Ecco alcuni degli errori di monitoraggio più comuni e come affrontarli.

Errore n.1: Fare affidamento sugli individui e sui processi guidati dall’uomo

Una situazione che abbiamo visto molte volte scorre un po’ così:

• Si è nel bel mezzo di una crisi – sei stato abbastanza fortunato da essere stato slashdotted?
• Viene apportata una modifica alle apparecchiature del vostro data center – viene aggiunto un nuovo volume al vostro NetApp in modo che possa servire come storage ad alta velocità per il vostro web tier.
• Muovendosi rapidamente, ci si dimentica di aggiungere il nuovo volume al monitoraggio di NetApp.

Dopo la crisi, tutti sono troppo occupati a tirare sospiri di sollievo per preoccuparsi di quel nuovo volume. Si riempie lentamente ma inesorabilmente o inizia a mostrare latenza, a causa di operazioni di IO elevate. Nessuno viene avvisato, e i clienti sono i primi a notarlo, a chiamare e a lamentarsi. Molto probabilmente, il CTO è il prossimo a chiamare.

Eliminate il più possibile la configurazione da parte di un individuo – non solo perché fa risparmiare tempo alle persone, ma perché rende il monitoraggio – e quindi i servizi monitorati – molto più affidabili.

Quando esaminate le caratteristiche della soluzione, considerate che:

• Esamini continuamente i dispositivi monitorati per le modifiche, aggiungendo automaticamente nuovi volumi, interfacce, container docker, pod Kubernetes, VIP load balancer, database e qualsiasi altra modifica nel monitoraggio. Vi informi poi tramite messaggio immediato in tempo reale o notifiche in batch.
• Fornisca il filtraggio e la classificazione delle modifiche rilevate per evitare il sovraccarico di avvisi.
• Esamini le vostre sottoreti, o anche il vostro account cloud hyperscale, e aggiunga automaticamente nuove macchine o istanze al monitoraggio.
• Crei grafici e crei spontaneamente dashboard intelligenti. Una dashboard grafica basata sulla somma delle sessioni su dieci server web utilizzati per visualizzare l’integrità del vostro servizio dovrebbe aggiornarsi automaticamente quando aggiungete altri quattro server. L’automazione di questa raccolta assicura la continuità della vostra panoramica aziendale.

Non dipendete dagli aggiornamenti manuali del monitoraggio per coprire aggiunte, spostamenti e cambiamenti.

Errore n. 2: Considerare un problema risolto quando il monitoraggio non è in grado di rilevare la ricorrenza

Si verificano interruzioni, anche quando si seguono buone pratiche di monitoraggio. Tuttavia, un problema non è risolto  senza aver garantito che il monitoraggio rilevi la causa principale o sia modificato per fornire un avviso tempestivo.

Per esempio, un’applicazione Java che subisce un’interruzione del servizio a causa di un gran numero di utenti che sovraccaricano il sistema, ha probabilmente mostrato un aumento del numero di thread occupati. Modificate il monitoraggio JMX per osservare questo aumento. Se  viene creata una soglia di alert su questa metrica o si utilizza una piattaforma di monitoraggio che supporta soglie dinamiche, la prossima volta si può ricevere un avviso in anticipo. Il preallarme fornisce almeno una finestra in cui evitare l’interruzione: il tempo di aggiungere un altro sistema per condividere il carico o attivare il meccanismo di riduzione del carico. La configurazione degli avvisi in risposta al fermo macchina vi permette, la prossima volta, di essere proattivi.

Questo è un principio molto importante. Il recupero del servizio è il primo passo, ma non significa che il problema debba essere chiuso o liquidato. E’ necessario essere soddisfatti degli avvisi che la vostra soluzione di monitoraggio ha dato prima del problema, e soddisfatti dei tipi di allarme e delle escalation che si sono attivati durante il problema. Il problema può essere uno di quelli che non possono essere segnalati in anticipo – i guasti catastrofici dei dispositivi possono verificarsi – ma questo processo di valutazione dovrebbe essere intrapreso per ogni evento che influisce sul servizio.

Errore n. 3: sovraccarico di alert

Il sovraccarico di alert e l’affaticamento è una delle condizioni più dannose. Un numero eccessivo di alert attivati ​​troppo frequentemente fa sì che le persone ignorino tutti gli avvisi.

È necessario prevenire questo:

• Adottare politiche di escalation ragionevoli che distinguano tra avvisi ed errori o livelli di allerta critici. Potrebbe non essere necessario svegliare le persone se NTP non è sincronizzato, ma se il volume del database principale ha una latenza di 200 ms e il tempo di transazione è di 18 secondi per un utente finale, ciò è critico. Dovete esserci, non importa l’ora.
• Indirizzare gli avvisi giusti alle persone giuste. Non avvisare il DBA in merito a problemi di rete e non informare il gruppo di rete di una transazione bloccata.
• Regolare delle soglie. Ogni avviso deve essere reale e significativo. Ottimizzare il monitoraggio per eliminare falsi positivi o avvisi attivati ​​sui sistemi di test.
• Indagare sugli avvisi ricevuti ​​quando tutto sembra a posto. Se si scopre che non ci sono stati problemi esterni, regolare le soglie o disabilitare l’avviso.
• Assicurarsi che gli avvisi vengano riconosciuti, risolti e cancellati. Centinaia di avvisi non riconosciuti sono troppo difficili per consentire una facile analisi di un problema immediato. Utilizzare il filtro degli avvisi per visualizzare solo i gruppi dei sistemi di cui si è responsabili.
• Analizzare gli avvisi principali per host o tipo di avviso. Indagare per vedere se la risoluzione dei problemi nel monitoraggio, nei sistemi o nei processi operativi può ridurre la frequenza di questi avvisi.

Errore n. 4:  Troppi strumenti di monitoraggio

Avete bisogno di un solo sistema di monitoraggio. Non implementate un sistema di monitoraggio per i server Windows, un altro per Linux, un altro per MySQL e un altro per lo storage. Anche se ogni sistema è altamente funzionale e capace, avere più sistemi non garantisce prestazioni del data center ottimali. I vostri team hanno bisogno di un posto unico per monitorare quante più tecnologie diverse possibili. Spesso si è tentati di utilizzare gli strumenti disponibili dai diversi vendor, ma questo significa che i vostri team si collegheranno a diverse piattaforme e avranno una visione distorta della situazione.

Anche un punto centrale per memorizzare i dettagli dei contatti del vostro team è vitale. Non si desidera avere informazioni aggiornate nei metodi di escalation di due sistemi ma non in altri due. Non si desidera avere la manutenzione programmata correttamente in un sistema di monitoraggio ma non in quello utilizzato per monitorare altri componenti degli stessi sistemi. Si verificheranno avvisi indirizzati in modo errato, con conseguente sovraccarico degli avvisi. Un sistema che notifica alle persone problemi che non possono riconoscere porta a “Oh … ho disattivato la notifica del mio cellulare”.

Errore n. 5: Non monitorare il sistema di monitoraggio

La vostra soluzione di monitoraggio può fallire. Ignorare questo fatto vi lascia solo esposti. Le aziende investono un capitale significativo per impostare il monitoraggio e comprendono il costo ricorrente in tempo del personale, ma poi non riescono a monitorare il sistema. Chi sa quando si verifica un guasto al disco rigido o alla memoria, un crash del sistema operativo o delle applicazioni, un’interruzione della rete presso il vostro ISP o un’interruzione di corrente? Non lasciate che il vostro sistema di monitoraggio vi lasci al buio circa l’integrità della vostra infrastruttura. Il sistema di monitoraggio deve comprende l’intero sistema, compresa la capacità di inviare avvisi. Se la connessione per l’invio della posta o SMS è fuori uso, il sistema di monitoraggio potrebbe rilevare un’interruzione, ma è evidente solo al personale che guarda la console. Un sistema che non può inviare avvisi non è d’aiuto.

Una falsa sicurezza è peggio che non avere alcun sistema di monitoraggio. Se non avete un sistema di monitoraggio, sapete che dovete eseguire dei controlli manuali dello stato di salute. Se si dispone di un sistema non monitorato perché non funzionante, non state eseguendo i controlli di integrità e state esponendo involontariamente l’azienda a un’interruzione non rilevata. Se i vostri team sviluppano una mancanza di fiducia nell’affidabilità del vostro strumento di monitoraggio, potrebbero iniziare a mettere in dubbio la validità degli avvisi che produce.

Riducete al minimo il rischio configurando un controllo del vostro sistema di monitoraggio da una posizione al di fuori della portata del sistema di monitoraggio. Oppure, scegliete una soluzione di monitoraggio che non solo sia ospitata in una posizione separata, ma che controlli anche l’integrità della propria soluzione di monitoraggio da più posizioni.

Il modo migliore per affrontare tutti questi errori è trovare una piattaforma di monitoraggio completa che faccia il lavoro per voi. LogicMonitor è una piattaforma di monitoraggio basata sul cloud che consente alle organizzazioni di vedere cosa sta arrivando prima che accada. Con funzioni AIOps avanzate, LogicMonitor aiuta i team a identificare e risolvere in modo proattivo i problemi dell’infrastruttura IT prima che possano influire negativamente sui sistemi business-critical e sulle prestazioni degli utenti finali.

Fonte: LogicMonitor