É triste, mas é verdade: muitos, e eu diria até mesmo a maioria dos profissionais de TI consideram alertas uma maldição. Afinal de contas, eles são chatos, barulhentos, geralmente inúteis e frequentemente falsos. Portanto, nós, profissionais de TI especializados nomonitoramento de TI, conhecemos bem aquele sentimento familiar dedesolamento que surge quando descobrimos que o alerta que criamos com tanto cuidado está sendo ignorado pela equipe que o recebe.
Nesse momento de desgosto profissional, você pode pensar em fazer alterações nos alertas para torná-los mais chamativos, mais interessantes e mais urgentes. Para alcançar esse objetivo, você pode até considerar escolher uma mensagem de alerta em um menu. Por exemplo:
· Irritado: Oi, equipe do servidor! Vocês pelo menos leem os alertas?!?
· Exagerado: PERIGO, WILL ROBINSON! O roteador EXPLODIRÁ em 5 minutos!
· Compreensivo (ou simplesmente patético): Oi, sou o servidor IIS e, de repente, ficou muito frio e escuro aqui. Será que alguém poderia acender as luzes novamente? Eu tenho medo do escuro.
Você também pode considerar pegar o caminho da isca de cliques. Por exemplo:
· O tempo de resposta deste servidor caiu para menos de 75%. Você não vai acreditar no que aconteceu depois!
· Mostramos aos administradores de sistema a falha de cluster às 2:15 da manhã. As reações que eles tiveram foram impagáveis.
· Você jurou que nunca reiniciaria este serviço. O que aconteceu às 2:15 da manhã mudará suas ideias para sempre.
· Três difíceis consultas de longa execução das quais você nunca escuta falar.
· Quente, super quente, quentíssimo! Esse mapa de calor sem fio revela as zonas mortas de Wi-Fi que seus pontos de acesso estão tentando esconder!
· Veja o que acontece quando esta VM ganha um vizinho barulhento. Você ficará chocado com os resultados!
Embora todas as abordagens acima sejam interessantes, para dizer o mínimo, elas, é claro, não cobrem o ponto principal: é mais difícil que parece criar uma alerta que seja significativo, informativo e acionável.Para combater esse problema e garantir que as equipes prestem atenção aos seus alertas no futuro, sem que seja necessário acessos de raiva, truques ou subornos, mostramos a seguir alguns problemas de alerta comuns, além dos motivos que os acionam e como resolvê-los.
Problema: vários alertas (e tíquetes) sobre o mesmo problema a cada poucos minutos
Motivo
Esse problema é chamado de ¨sawtoothing¨ (movimento de serra) edescreve uma situação em que um determinado incidente ou condição acontece, é resolvido, acontece novamente, e assim por diante; e o sistema de monitoramento cria um novo alerta cada vez que isso acontece.
Solução
Para resolver a questão, primeiramente você deve entender que algumasocorrências de ¨sawtoothing¨ indicam um problema real que precisa ser corrigido. Por exemplo, um dispositivo que é repetidamente reinicializado. Mas geralmente isso acontece porque um dispositivo está “oscilando” no limite do disparador; por exemplo, quando um alerta de CPU é configurado para disparar a 90% e um dispositivo fica flutuando entre 88% e 92%.
Estas são algumas das abordagens mais comuns para a resolução do problema:
- Defina um atraso baseado em tempo no disparador de alerta quedetermine que o dispositivo precise ficar acima de um determinado percentual da CPU por mais de um número de minutos predefinido. Assim, o alerta só encontrará dispositivos que estejam consistente e continuamente acima do limite.
- Use a opção de redefinição incorporada em todas as boas soluções demonitoramento e configure-a como um valor abaixo do valor do disparador. Por exemplo, defina o disparador quando a CPU ficar acimade 90% por 10 minutos, mas só redefina o alerta quando ele ficar abaixo de 80% por 20 minutos. Essa opção de redefinição estabelece um certo padrão de estabilidade no ambiente.
- Use a API do sistema de emissão de tíquetes para criar uma comunicação bidirecional entre a solução de monitoramento e o sistema de emissão de tíquetes que garanta que não será aberto um novo tíquete se já houver um tíquete existente para um problema específico no dispositivo.
Problema: Um dispositivo importante fica inativo (por exemplo, o roteador de borda em um local remoto) e a equipe é bombardeada por alertas referentes a todos os outros dispositivos do local
Motivo
Às vezes, quando a visibilidade de um determinado dispositivo é prejudicada, os sistemas de monitoramento acham que está ocorrendo ¨inatividade¨. No entanto, isso não significa necessariamente que o dispositivo está inativo; o upstream de um dispositivo pode estar inativo, fazendo com que nada mais possa ser monitorado enquanto ele não voltar à atividade.
Solução
Qualquer solução de monitoramento que preste tem uma opção que permite suprimir alertas com base em conexões ¨upstream¨ ou ¨pai-filho¨. Verifique se essa opção está habilitada e se a solução demonitoramento compreende as dependências de dispositivo do ambiente.
Problema: É necessário configurar um grande número de alertas porque as máquinas são diferentes umas das outra.
Motivo
Você pode se achar tendo que configurar o mesmo alerta geral (utilizaçãode CPU, disco cheio, aplicativo inativo, etc.) para um enorme número dedispositivos, pois cada máquina exige uma definição levemente diferentepara limite, tempo, destinatário ou qualquer outro elemento.
Solução
Nós, engenheiros de monitoramento, nos encontramos nessa situação quando nós (ou a ferramenta que estamos usando) não utilizamos campos personalizados. Em outras palavras, qualquer solução demonitoramento sofisticada deve permitir o uso de propriedades personalizadas para elementos como ¨CPU_Critical_Value¨. Isso édefinido por dispositivo, e o alerta passe de ¨Alerta quando utilização depercentual de CPU é >= 90%¨ para ¨Alerta quando a utilização depercentual de CPU é >= CPU_Critical_Value¨.
Essa solução permite que cada sistema tenha seu próprio limite personalizado, mas um único alerta seja usado para todos eles. Essa mesma técnica pode ser usada para destinatários de alertas. Em vez deter um alerta separado mas idêntico por CPU para as equipes de servidor, rede e armazenamento, cada dispositivo pode ter um campo personalizado chamado ¨Owner_Group_Email¨ que tenha um nome degrupo de e-mail. Você, então, cria um único alerta para ser enviado parao que está indicado no campo.
Problema: Determinados dispositivos disparam em determinados momentos porque o trabalho que eles estão realizando causam sobrecarga.
Motivo
Durante o curso de negócios regular, alguns sistemas apresentam períodos de alta utilização, que são completamente normais, mastambém completamente acima da taxa de execução habitual. Isso pode acontecer devido ao processamento de relatórios de fim do mês; sequências de compilação de código realizadas à noite ou durante o fimde semana; ou qualquer outra operação cíclica e previsível.
O problema é que o limite normal para a condição em questão é bom, mas o valor de ¨alto uso¨ está acima desse limite. Em consequência disso, um alerta é disparado. Contudo, se definir o limite do sistema como o nível de ¨alto uso¨, você deixará passar problemas importantes que geralmente estão abaixo do limite mais alto.
Solução
Em vez de disparar um limite de acordo com um valor definido, mesmo que ele seja definido por dispositivo como descrito anteriormente, você pode usar os dados de monitoramento em seu benefício. Lembre-se: omonitoramento não consiste em um alerta ou uma mensagem eletrônica, nem tampouco um ponto que fica piscando na tela. Omonitoramento não é nada mais (nem menos) que a coleta regular, estável e contínua de um conjunto consistente de métricas de um grupode dispositivos. Todo o resto (alertas, e-mails, pontos que piscam, etc.) é o feliz subproduto do qual você desfruta quando faz o monitoramentocorretamente.
Então, se você costuma coletar todos esses dados, por que não os analisa para ver o que é ¨normal¨ para cada dispositivo? Isso se chama ¨linha de base¨ e reflete não apenas uma média geral, mas também a taxa de execução normal por dia e até mesmo por hora. Se você puderderivar esse valor de ¨linha de base¨, seu disparador de alerta poderá passar de ¨Alerta quando a utilização de percentual de CPU é >= <algum valor fixo>¨ para ¨Alerta quando a utilização de percentual deCPU é >= 10% acima da linha de base para esse período¨.
Os profissionais de TI experimentaram estes estranhos truques demonitoramento. Você ficará chocado com os resultados!
Quando os engenheiros de monitoramento implementam e usam ao máximo os recursos de suas soluções de monitoramento, os resultados são liberadores para todas as partes envolvidas. Os alertas se tornam mais específicos e menos frequentes, o que dá às equipes mais tempopara realmente concluir o trabalho. Isso, por sua vez, faz com que essas mesmas equipes confiem mais nos alertas e reajam a eles a tempo, o que beneficia toda a empresa. O melhor de tudo é que todos experimentam o verdadeiro valor oferecido pelo bom monitoramento e começam a solicitar que os engenheiros de monitoramento criem alertas e desenvolvam insights que ajudem a estabilizar e aprimorar o ambiente ainda mais.
¨A equipe de monitoramento permitiu que a empresa economizasse $$$¨ não é um título falso inventado para gerar cliques. Com um poucode trabalho, isso pode acontecer em todas as organizações.
(*) Leon Adato, gerente técnico da SolarWinds
Site: CIO
Data: 02/08/2016
Hora: 9h04
Seção: Tecnologia
Autor: Leon Adato
Foto: ——
Link: http://cio.com.br/tecnologia/2016/08/02/truques-e-iscas-para-alertas-de-monitoramento-de-ti/