por que a carga da CPU não deve (geralmente) ser um alerta crítico.

uma questão que muitas vezes surge no monitoramento é como definir níveis de alerta e escalações, e que nível para definir vários alertas em – crítico, erro ou aviso.

supondo que você tenha erros e alertas críticos definidos para notificar as equipes por pager / telefone e alertas críticos com um tempo de escalonamento mais curto, Aqui estão algumas diretrizes simples:

alertas críticos devem ser para eventos que tenham efeito de impacto imediato do cliente. Por exemplo, um IP virtual de produção em um balanceador de carga monitorado caindo, pois não possui serviços disponíveis para rotear o tráfego. O site está em baixo, então Página todos.

os alertas de erro devem ser para eventos que requerem atenção imediata e que, se não resolvidos, aumentam a probabilidade de ocorrer um evento que afeta a produção. Para continuar com o exemplo do balanceador de carga, um erro deve ser acionado se o IP Virtual tiver apenas um servidor de back – end em funcionamento para rotear o tráfego-agora não há redundância, portanto, uma falha pode deixar o site offline.

avisos, que normalmente recomendamos ser enviados apenas por e-mail, são para todos os outros tipos de eventos. A perda de um único servidor de back-end de um IP Virtual quando há 20 outros servidores funcionando não garante que ninguém seja acordado à noite.

ao decidir qual nível atribuir alertas, considere a função principal do dispositivo. Por exemplo, no caso de uma matriz de armazenamento NetApp, a função do dispositivo é atender solicitações io de leitura e gravação. Portanto, a principal coisa para monitorar o NetApps deve ser a disponibilidade e o desempenho (latência) dessas solicitações de leitura e gravação. Se um volume estiver atendendo solicitações com alta latência – como 70 ms por solicitação de gravação-isso deve ser um alerta de Nível de erro (em algumas empresas, isso pode ser apropriado para configurar como um alerta de nível crítico, mas geralmente um alerta de desempenho crítico deve ser acionado somente se o desempenho do aplicativo final se degradar inaceitavelmente.) No entanto, se a carga da CPU no NetApp for de 99% por um período, Mesmo que pareça alarmante, sugiro que seja tratada apenas como um alerta de Nível de aviso. Se a latência não é afetada, por que acordar as pessoas à noite? Envie um alerta de E-mail para que o problema possa ser investigado, mas se a função do dispositivo não estiver prejudicada, não reaja demais. (Se desejar, você pode definir suas escalações de alerta para que tais condições resultem em páginas se não corrigidas ou não reconhecidas por mais de 5 horas, digamos.)

a sobrecarga de alerta é um perigo maior para a maioria dos datacenters do que a maioria das pessoas imagina. O pensamento é muitas vezes ” se um alerta é bom, mais deve ser melhor. Em vez disso, concentre – se em identificar as principais funções dos dispositivos-defina alertas de Nível de erro nessas funções e use Avisos para informá-lo sobre condições que possam prejudicar essas funções ou para ajudar na solução de problemas. (Se a latência em um NetApp for alta e a carga da CPU também estiver em alerta, isso obviamente ajuda a diagnosticar o problema, em vez de procurar uma atividade de volume incomum.)

Reserve alertas críticos para o desempenho e a disponibilidade do sistema como um todo.

com o monitoramento hospedado pelo LogicMonitor, as definições de alerta para todos os dispositivos de data center têm seus limites de alerta predefinidos da maneira acima-essa é uma maneira de ajudar a fornecer monitoramento significativo em minutos.