Checkmk sem falsos positivos: como calibrar alertas para a equipe agir só quando o problema é real

Três ajustes no Checkmk que fazem cada alerta corresponder a um problema real e ajudam a sua equipe a ir direto à causa.

5 min de leitura

Se tudo é urgente, nada é urgente. Quando o monitoramento avisa sobre qualquer oscilação, a sua equipe passa o dia triando mensagens, o e-mail de alerta começa a ser ignorado e o incidente que importa fica escondido no meio dos outros.

A boa notícia é que isso raramente é defeito da ferramenta. Quase sempre é calibração, e o Checkmk tem os recursos certos para ela. Este guia mostra três ajustes que separam o alerta que gera trabalho do alerta que gera ação.

Resumo rápido

  • Com os hosts pais (parents) configurados, uma falha de rede gera um alerta sobre a causa, e os servidores atrás dela ficam como inalcançáveis, sem notificação própria.
  • Limites ligados a períodos de tempo permitem tratar a mesma CPU alta como esperada durante o backup da madrugada e como problema no horário comercial.
  • Repetir a verificação e atrasar a notificação por alguns minutos evita acordar a equipe por quedas curtas que se resolvem sozinhas.
  • O objetivo é que cada notificação corresponda a um problema real que precisa de alguém agindo agora.

O que muda quando o alerta é calibrado

Antes da calibração, o monitoramento avisa sobre tudo. A equipe se acostuma a receber dezenas de mensagens por dia, deixa de ler parte delas, e o problema real chega misturado aos avisos que não pedem nada.

Depois da calibração, chegam os problemas reais. Cada notificação tem dono, contexto e um motivo claro para alguém agir. A quantidade cai, e a confiança da equipe no monitoramento sobe.

1. Um problema, um alerta

O primeiro ajuste é dizer ao Checkmk como os seus equipamentos dependem uns dos outros. Isso se faz definindo os hosts pais (parents) de cada host, por exemplo o roteador ou o switch pelo qual um servidor é alcançado. Você pode informar os pais nas propriedades do host ou usar a varredura de pais do próprio Checkmk, que descobre por traceroute o último gateway antes de cada host.

Sem essa configuração, quando o roteador cai, o monitoramento vê todos os servidores atrás dele como DOWN e notifica um a um. Com os pais definidos, o Checkmk sabe distinguir: o roteador fica DOWN e os servidores atrás dele passam ao estado UNREACH (inalcançável), que por padrão não gera notificação. O alerta que chega é um só, e aponta para a causa.

Para a sua equipe, isso significa ir direto ao roteador, sem perder tempo investigando servidores que estão funcionando.

2. O alerta entende o horário da sua operação

CPU a 90% é problema? Depende do momento. Durante o backup da madrugada, é o comportamento esperado. Ao meio-dia, num servidor que atende usuários, merece atenção.

O Checkmk permite cadastrar períodos de tempo (time periods) e vincular a eles os limites de certas verificações. Assim, a mesma métrica é avaliada de acordo com o que é normal naquele horário: um limite para a noite, outro para o expediente.

Nas edições comerciais do Checkmk, há ainda o monitoramento preditivo (predictive levels). Ele calcula uma curva de referência a partir do histórico da própria métrica, por exemplo o mesmo dia da semana nas últimas semanas, e define os limites em relação a essa curva. Funciona bem para métricas com padrão regular, como carga de CPU e tráfego.

Na prática, a regra passa a refletir a rotina real da sua operação, e não um número fixo que vale para qualquer hora do dia.

3. A regra dos cinco minutos

Quedas curtas de rede acontecem, e muitas se resolvem em segundos. Se o monitoramento notifica no primeiro sinal de falha, alguém da equipe é acordado de madrugada por algo que já voltou quando ele abre o notebook.

O Checkmk oferece dois ajustes para isso, e eles se complementam:

  • Maximum number of check attempts for services (e a regra equivalente para hosts): o problema só vira estado definitivo (hard state) e gera notificação depois de algumas verificações seguidas com falha.
  • Delay service notifications e Delay host notifications: a notificação espera o tempo definido e, se o serviço voltar ao normal antes disso, nada é enviado.

Para serviços que não exigem resposta imediata, uma espera de alguns minutos, por exemplo cinco, costuma ser um bom ponto de partida. Serviços críticos podem ter uma espera menor, definida caso a caso com quem responde por eles.

Vale combinar esses ajustes com a detecção de oscilação (flapping). Quando um serviço alterna rapidamente entre OK e falha, o Checkmk o marca como flapping, avisa uma vez e deixa de notificar cada mudança de estado até ele se estabilizar.

Por onde começar no seu ambiente

Um caminho simples para aplicar os três ajustes:

  1. Liste os alertas das últimas semanas e marque quais geraram alguma ação.
  2. Para os que não geraram ação, identifique o motivo: falha em cascata, horário esperado ou queda curta.
  3. Aplique o ajuste correspondente: hosts pais, períodos de tempo ou tentativas e atraso de notificação.
  4. Revise o resultado depois de algumas semanas e repita.

Esse ciclo é contínuo. Ambientes mudam, servidores entram e saem, e a calibração precisa acompanhar.

Fontes

O próximo passo

Calibrar alertas é trabalho de detalhe, e a sua equipe sabe melhor do que ninguém o que é normal na sua operação. O que costuma faltar é tempo para revisar regra por regra.

A Lavineda foi a primeira parceira oficial Checkmk no Brasil, desde 2023, e trabalha também com Nagios XI e PRTG. Você pode conhecer a plataforma na página do Checkmk ou, se preferir que a calibração e o acompanhamento diário fiquem com a nossa equipe, ver como funciona o Network Care.

Numa conversa de diagnóstico gratuita, olhamos o seu cenário com você e mostramos onde estão os alertas que não pedem ação.