Artigo/12 min de leitura/Observabilidade

Ruído de monitoramento: o problema que nenhuma ferramenta resolve sozinha.

Você não tem um problema de monitoramento. Tem um problema de ruído. Isso muda completamente o que você deve comprar, e o que deve parar de comprar.

PT Pedro Tebaldi · PM @ KeepGreen · 17 mai 2026

Em mais de duas décadas operando monitoramento para empresas brasileiras, tem uma cena que se repete em quase todo cliente novo. O time abre o painel, Zabbix, OpMon, o que for, e mostra 1.400 problemas ativos. E ri. Não é riso de orgulho. É riso de quem desistiu.

"A gente já nem olha", o gestor diz. "Quando importa, a galera grita no WhatsApp."

Esse é o estado real da observabilidade na maior parte das empresas médias brasileiras. Não é falta de monitoramento. É excesso. E nenhuma ferramenta nova de IA, painel mais bonito ou "AIOps revolucionário" resolve isso sozinha, porque o problema não é tecnológico. É de volume sem hierarquia.

O caminho que parece óbvio, e está errado

Quando uma empresa percebe que está afogada em alerta, a primeira reação costuma ser comprar uma ferramenta que centraliza o monitoramento. Mais um console, mais um SaaS, mais um lugar para o alerta cair. Isso resolve um problema secundário, a fragmentação de fontes, e amplia o problema principal: agora todos os alertas chegam ao mesmo lugar, mais rápido, e o time, exausto, ignora todos juntos.

Centralizar ruído não é resolver ruído. É concentrar a explosão.

A segunda reação é mais sofisticada e mais cara: contratar uma plataforma de AIOps para correlacionar incidentes. A IA olha o mar de alertas, agrupa por similaridade e devolve incidentes agregados. Funciona melhor que nada, mas tem dois problemas grandes:

  • Custo computacional alto. A IA processa 90% de lixo só para descobrir, no fim, que era lixo.
  • Confiabilidade variável. Modelos alucinam quando o input é muito barulhento. A precisão cai exatamente quando você mais precisa dela, durante uma tempestade de eventos.

A ordem está errada. Você não deve analisar primeiro e filtrar depois. Deve filtrar primeiro e analisar depois.

A camada que quase ninguém valoriza

Filtro determinístico de eventos é a coisa mais subestimada de observabilidade. É código antigo, sem hype, sem demo bonita. E é o que faz a diferença entre 1.400 alertas por dia e 40.

No KeepGreen esse filtro tem seis camadas, todas determinísticas, nenhuma IA, todas configuráveis por cliente. Elas rodam nesta ordem:

CamadaO que descartaVolume típico
DeduplicaçãoMesmo evento, mesmo host, em janela curta30–50%
HysteresisFlapping, sobe-desce, sobe-desce10–20%
ThrottleRajada absurda, 200 alertas em 1s5–10%
Supressão topológicaSintoma de uma causa já capturada10–25%
Inibição por severidadeWarning enquanto há disaster no mesmo recurso5–10%
Detecção de crônicoO alerta que dispara há mesesmarca, não descarta

Somando, o efeito é de 60% a 80% menos eventos chegando na camada de IA e, portanto, na sua caixa de notificação. Em alguns clientes vimos picos de 91%.

Filtrar não é mascarar

Nada é deletado. Cada evento descartado tem trilha de auditoria: qual camada cortou, com que regra, em que janela. Você audita o filtro mês a mês e calibra.

Por que isso vem antes da IA, não depois

Quando você roda IA em cima de um stream já filtrado, três coisas mudam:

  1. 01A IA olha o sinal certo. Causa, não sintoma. Diagnóstico, não eco.
  2. 02O custo cai em ordem de grandeza. Você não paga token para o modelo ler 1.000 duplicatas do mesmo evento.
  3. 03A IA fica mais confiável. Menos contexto irrelevante significa menos chance de alucinar.

Existe um meme técnico que diz "garbage in, garbage out". Vale aqui em dobro. A IA do seu AIOps é tão boa quanto a comida que você dá para ela.

O que os clientes mais valorizam

Sobre o stream já limpo, o KeepGreen entrega bastante coisa: causa raiz por IA, post-mortem automático no recovery, ligação telefônica em português às 3h da manhã, escalação no WhatsApp e abertura automática de chamado no service desk. Mais recentemente, passou a classificar a frota por dimensionamento, com recomendação de upgrade ou downsize no módulo de FinOps.

Tudo isso pesa. Mas o que os clientes mencionam primeiro, mês após mês, não é nenhum desses recursos. É o número de eventos que o filtro corta. Ver que, dos 1.400 alertas do mês passado, só 187 chegaram, e que desses 187 apenas 12 exigiram ação humana, é o que muda a relação do time com o painel.

"Menos alarme" é uma promessa que o cliente sabe medir. Por isso é a primeira coisa que ele nota, e a mais difícil de abrir mão depois.

Como saber se você está sofrendo disso

Alguns sintomas. Se você marcar três ou mais, é hora de tratar ruído antes de qualquer outra coisa:

  • Quando alguém menciona um host na reunião, ninguém sabe se está vermelho no painel, porque tudo está vermelho.
  • O canal de alertas no Slack está mutado para todo mundo, inclusive para o coordenador.
  • Você descobre incidentes pelo cliente, não pelo monitoramento.
  • Há alertas que ninguém entende no painel há semanas, e ninguém remove porque "vai que um dia significa alguma coisa".
  • Os mesmos quatro ou cinco problemas voltam toda semana sem virar tarefa.

Se nada disso descreve sua operação, parabéns. Se alguns descrevem, ainda dá para resolver com calibração e supressão. Se todos descrevem, você não precisa de mais ferramenta. Precisa de uma central de alertas e insights. Pessoa ou produto, mas alguém que faça a triagem.

Em uma linha

Trate ruído antes de tratar inteligência. Você vai resolver mais problemas, gastar menos dinheiro e, surpresa, fazer sua IA funcionar melhor. É a coisa mais chata do mundo de implementar. Por isso quase ninguém implementa direito, e por isso é o trabalho mais valioso, e mais invisível, que o KeepGreen faz.

Quer ver isso aplicado no seu ambiente?

Levamos 30 minutos. Olhamos seu painel, mostramos o que o filtro cortaria, você decide se faz sentido seguir.

Falar com especialista →
KeepGreen © 2026 KeepGreen · Porto Alegre · Brasil · uma operação OpServices