Perché il carico della CPU non dovrebbe (di solito) essere un avviso critico.

Una domanda che spesso si pone nel monitoraggio è come definire i livelli di allarme e le escalation e a quale livello impostare vari avvisi: critico, Errore o Avviso.

Supponendo che tu abbia errori e avvisi critici impostati per notificare i team tramite cercapersone / telefono e avvisi critici con un tempo di escalation più breve, ecco alcune semplici linee guida:

Gli avvisi critici dovrebbero essere per eventi che hanno un impatto immediato sul cliente. Ad esempio, un IP virtuale di produzione su un sistema di bilanciamento del carico monitorato in calo, in quanto non ha servizi disponibili per instradare il traffico verso. Il sito è giù, così pagina tutti.

Gli avvisi di errore dovrebbero riguardare eventi che richiedono attenzione immediata e che, se non risolti, aumentano la probabilità che si verifichi un evento che influisce sulla produzione. Per continuare con l’esempio load balancer, è necessario attivare un errore se l’IP virtuale ha solo un server backend funzionante a cui instradare il traffico: ora non c’è ridondanza, quindi un errore può portare il sito offline.

Gli avvisi, che in genere consigliamo di inviare solo via e-mail, sono per tutti gli altri tipi di eventi. La perdita di un singolo server backend da un IP virtuale quando ci sono altri server 20 funzionanti non garantisce che nessuno venga svegliato nella notte.

Al momento di decidere quale livello assegnare gli avvisi, considerare la funzione primaria del dispositivo. Ad esempio, nel caso di un array di storage NetApp, la funzione del dispositivo è quella di servire richieste di I / O in lettura e scrittura. Quindi la cosa principale per monitorare NetApps dovrebbe essere la disponibilità e le prestazioni (latenza) di queste richieste di lettura e scrittura. Se un volume sta servendo richieste con latenza elevata, ad esempio 70 ms per richiesta di scrittura, questo dovrebbe essere un avviso di livello di errore (in alcune aziende, potrebbe essere appropriato configurare come avviso di livello critico, ma di solito un avviso di prestazioni critiche dovrebbe essere attivato solo se le prestazioni dell’applicazione finale si degradano in modo inaccettabile.) Tuttavia, se il carico della CPU su NetApp è del 99% per un periodo, anche se sembra allarmante, suggerirei di essere trattato solo come un avviso di livello di avviso. Se la latenza non è influenzata, perché svegliare le persone di notte? Invia un avviso e-mail in modo che il problema possa essere indagato, ma se la funzione del dispositivo non è compromessa, non reagire eccessivamente. (Se lo si desidera, è possibile definire le escalation degli avvisi in modo che tali condizioni risultino in pagine non corrette o non riconosciute per più di 5 ore, ad esempio.)

Il sovraccarico di avviso è un pericolo più grande per la maggior parte dei datacenter di quanto la maggior parte delle persone si renda conto. Il pensiero è spesso “se un avviso è buono, più deve essere migliore.”Invece, concentrati sull’identificazione delle funzioni principali dei dispositivi: imposta avvisi a livello di errore su tali funzioni e usa gli avvisi per informarti sulle condizioni che potrebbero compromettere tali funzioni o per aiutare nella risoluzione dei problemi. (Se la latenza su una NetApp è elevata e anche il carico della CPU è in allerta, ciò ovviamente aiuta a diagnosticare il problema, invece di cercare un’attività di volume insolita.)

Riserva avvisi critici per le prestazioni e la disponibilità del sistema nel suo complesso.

Con LogicMonitor hosted monitoring, le definizioni di avviso per tutti i dispositivi del data center hanno le loro soglie di avviso predefinite nel modo sopra descritto: questo è un modo in cui aiutiamo a fornire un monitoraggio significativo in pochi minuti.