Toda equipe de TI tem uma história como essa.
Um servidor de produção aciona um alerta de CPU às 23h. O administrador da rede vê a CPU em 83% e a ignora porque o servidor sempre aumenta durante seu trabalho noturno em lote.
Três semanas depois, o mesmo servidor atinge 83% da CPU às 14h. numa terça-feira. Desta vez, um processo descontrolado está causando o problema. Mas o alerta se parece exatamente com aqueles que a equipe tem ignorado, por isso é ignorado novamente.
O problema não é o engenheiro. É o limite fixo.
O problema com limites estáticos
Os limites estáticos são fáceis de definir: CPU a 80%, memória a 75%, disco a 85%. Você pode escolher uma linha de base que pareça razoável para sua rede e aplicá-la em seus servidores.
Mas o problema é que os servidores não se comportam da mesma maneira o tempo todo, nem mesmo iguais uns aos outros. Um limite que faz sentido para uma carga de trabalho pode ser completamente errado para outra. Considere o que acontece em ambientes reais:
- Um servidor SQL pode funcionar regularmente com 70% da CPU durante o horário comercial, enquanto fica com 15% durante a noite. Um limite de 80% pode ser acionado repetidamente durante o pico normal de atividade, mas não detectar um problema quando a CPU atingir 65% em um domingo tranquilo.
- Um servidor web a execução de exportações em lote agendadas pode atingir 90% da CPU por 20 minutos todas as noites à 1h. Com um limite de 80%, o mesmo alerta aparece todas as noites. Eventualmente, a equipe sabe que é rotina e deixa de prestar atenção.
- Um servidor de arquivos pode preencher gradualmente seu volume primário ao longo de vários meses. O alerta de disco dispara a 85%, alguém arquiva arquivos antigos e tudo parece bem por um tempo. Dois meses depois, o alerta dispara novamente. A equipe não precisa apenas de outro aviso de espaço em disco. Eles precisam saber com que rapidez o armazenamento está sendo preenchido e quando realmente ficarão sem espaço.
Em cada caso, o limite estático está funcionando bem com base nas condições. Mas não diz à equipe se algo está realmente errado. É aí que a fadiga do alerta se torna perigosa. O verdadeiro problema não são apenas muitos alertas. Acontece que falsos positivos repetidos permitem que as equipes ignorem alertas, incluindo aqueles que realmente precisam de atenção.
O que o monitoramento adaptativo faz de diferente?
O monitoramento adaptativo altera a pergunta de “Esta métrica ultrapassou um limite fixo?” para “Esta métrica está se comportando de maneira incomum para este servidor, neste momento, com base em seu padrão normal?”
Em vez de aplicar o mesmo limite em todos os lugares, o monitoramento adaptativo aprende como é o normal para cada servidor ao longo do tempo e cria uma linha de base que leva em consideração:
- Padrões de hora do dia: Um servidor que usa regularmente alta CPU durante o horário comercial não deve acionar o mesmo alerta às 10h que acionaria às 2h.
- Padrões do dia da semana: Trabalhos agendados, janelas de manutenção e ciclos de negócios semanais podem afetar o uso de recursos. O monitoramento adaptativo leva em conta esses padrões recorrentes, em vez de tratar cada pico como um problema.
- Tendências de carga de trabalho: Se o uso da CPU de um servidor tiver aumentado constantemente nos últimos meses, a linha de base poderá se ajustar a essa tendência em vez de tratar cada aumento como uma anomalia.
Isso ajuda você a tratar o desvio correto como uma anomalia, e não apenas quando uma métrica ultrapassa os limites.
Exemplo
Vamos pegar o SQL Server. Com o tempo, um modelo adaptativo aprende que o uso da CPU normalmente atinge cerca de 72% durante o horário comercial. Portanto, em vez de disparar um alerta sempre que o uso aumenta, ele define um limite mais alto, em torno de 85%, para esse período.
O monitoramento adaptativo detecta o comportamento incomum quando é importante e ignora a atividade normal desse servidor. Os limites estáticos geralmente fazem o oposto.
Como o aprendizado de máquina potencializa isso na prática?
As plataformas AIOps modernas usam aprendizado de máquina para entender como as métricas se comportam ao longo do tempo e detectar padrões que estão fora do comportamento normal. Em vez de depender de um limite fixo, o sistema aprende o que é normal para cada servidor e ajusta os alertas de acordo.
Uma abordagem típica é assim:
- Colete métricas ao longo do tempo. O sistema reúne CPU, memória, E/S de disco e outras métricas de desempenho para cada dispositivo.
- Crie uma linha de base para cada métrica. O aprendizado de máquina analisa os dados para identificar tendências, padrões recorrentes e variações normais. Por exemplo, ele pode calcular o uso típico da CPU P95 para diferentes janelas de tempo durante várias semanas.
- Crie limites dinâmicos. Os limites críticos e de aviso são então definidos em relação à linha de base, em vez de usar o mesmo valor fixo em todos os lugares. Por exemplo:
- Aviso: cerca de 15% acima do pico esperado
- Crítico: cerca de 30% acima do pico esperado
- Continue aprendendo à medida que as condições mudam. À medida que as cargas de trabalho e os padrões de uso evoluem, a linha de base é atualizada com novos dados. Se houver uma grande mudança na infraestrutura, as equipes também poderão desencadear um novo período de aprendizagem.
- Alertar quando o comportamento mudar. O sistema emite um alerta quando uma métrica sai significativamente do padrão esperado; não simplesmente porque ultrapassou um número absoluto.
A principal diferença é que o limite reflete o que aquele servidor específico normalmente faz, em vez de um valor que alguém configurou anos atrás e nunca revisou.
O monitoramento adaptativo também pode detectar problemas que os limites estáticos ignoram completamente. Suponha que um servidor normalmente funcione com 55% da CPU durante o horário comercial, mas cai repentinamente para 20%. Um limite estático de 80% não vê nada de errado. Mas essa queda repentina pode significar que um processo crítico parou de processar solicitações.
Implementando limites adaptativos com ManageEngine OpManager
O mecanismo AIOps do OpManager, desenvolvido pela Zia, traz limites adaptativos para o monitoramento de servidores sem exigir cientistas de dados ou configuração de modelo complexo.
Como funcionam os limites adaptativos no OpManager?
A Zia analisa dados de desempenho de dispositivos monitorados e aprende o comportamento normal de métricas como CPU, memória, E/S de disco, uso de rede e tempo de resposta. Durante o período de aprendizagem, ele cria uma linha de base para cada dispositivo e métrica.
Uma vez estabelecida a linha de base, o OpManager pode usar limites adaptativos juntamente ou em vez dos limites estáticos tradicionais. Ele também fornece dados de previsão, ajudando as equipes a entender a direção de uma métrica, em vez de olhar apenas para seu valor atual.
Configurando limites adaptativos baseados em Zia
No console do OpManager:
- Vá para Configurações -> Monitoramento -> Zia AI -> Limites Adaptáveis.
- Selecione o dispositivo ou grupo de dispositivos onde deseja ativar o monitoramento adaptativo.
- Escolha as métricas que deseja monitorar, como uso de CPU, memória, disco ou rede.
- Defina o nível de sensibilidade para controlar o quanto uma métrica deve se desviar de sua linha de base antes que um alerta seja acionado. Uma sensibilidade mais baixa significa menos alertas, enquanto uma sensibilidade mais alta pode detectar desvios menores.
- Escolha se os limites adaptativos devem substituir limites estáticos existentes ou trabalhar junto com eles durante a transição.
O OpManager também inclui o Zia Insights, que transforma anomalias detectadas em resumos fáceis de entender, ajudando as equipes a ver rapidamente o que está acontecendo em seu ambiente. O Zia pode ser executado na nuvem ou com uma instância Ollama implantada localmente para equipes que preferem continuar monitorando os dados em seu próprio ambiente.
Correlação de alerta: a outra metade do problema
Os limites adaptativos ajudam a reduzir falsos positivos: alertas que são acionados mesmo quando tudo está funcionando normalmente. Mas o verdadeiro desafio são as tempestades de alertas, onde uma única falha desencadeia uma enxurrada de alertas relacionados.
Por exemplo, se um switch de rede falhar e 40 servidores ficarem inacessíveis, o sistema de monitoramento poderá gerar 40 alertas separados. Cada alerta é tecnicamente correto, mas analisá-los individualmente torna mais difícil ver o que realmente deu errado. A verdadeira questão é a mudança; os servidores inacessíveis são apenas sintomas.
A correlação de alertas baseada em AIOps conecta esses alertas relacionados e os agrupa em um único incidente, ajudando as equipes a identificar a provável causa raiz com mais rapidez. A análise de causa raiz do OpManager correlaciona alertas com base em fatores como caminhos de rede, dependências de dispositivos e tempo, e então aponta automaticamente para a causa mais provável.
O que isso significa para as equipes de plantão?
O objetivo não é apenas reduzir alertas. É para garantir que os alertas que as equipes recebem realmente sejam importantes.
Se uma equipe receber 20 alertas úteis por dia, ela poderá investigar cada um deles. Mas se receberem 200 alertas e a maioria deles for ruído, eventualmente começarão a ignorá-los. Isso, por sua vez, leva à perda de uma possível interrupção.
Isso também afeta o MTTR. Quando um alerta é significativo, a equipe pode começar a resolver o problema imediatamente. Quando os alertas costumam ser falsos positivos, a primeira pergunta é: “Isso é realmente um problema?” Essa hesitação pode retardar a resposta.
Em 2026, a recolha de métricas já não é suficiente. O verdadeiro valor está em compreender quais mudanças são normais, quais precisam de atenção e quais sinalizam um problema real.
Resumo
Os limites estáticos funcionavam bem quando os ambientes de TI eram menores e as cargas de trabalho eram mais previsíveis. Hoje, a infraestrutura está em constante mudança, tornando os limites fixos menos eficazes. O monitoramento adaptativo usa linhas de base aprendidas, limites dinâmicos, detecção de anomalias e correlação de alertas para manter o monitoramento preciso à medida que o ambiente muda. O objetivo não é gerar mais alertas. É entregar o alerta certo, para o dispositivo certo, com contexto suficiente para que a equipe tome medidas imediatas.
Experimente o ManageEngine OpManager gratuitamente por 30 dias →
Source link
