A gente já escreveu por aqui que, até a beta 2 do Zabbix 8.0 (9 de julho de 2026), o CEP — Complex Event Processing — seguia listado como "em desenvolvimento" no roadmap oficial, sem aparecer confirmado em nenhuma nota de lançamento. Isso mudou: a documentação atual do Zabbix 8.0 já traz o Complex Event Processing Engine com página própria, caminho de configuração definido e escopo de recurso detalhado. Saiu de promessa pra funcionalidade documentada.
O que o CEP faz, na prática
O CEP entra em Data collection > Event processing, na mesma tela onde já vivem as regras de correlação clássicas — o filtro por tipo separa as regras antigas das novas. Um jeito direto de descrever o que ele automatiza:
- Deduplicação de eventos que representam o mesmo problema, em vez de abrir um alarme por trigger disparada.
- Janela de tempo e agrupamento, pra tratar uma sequência de eventos correlacionados como uma unidade, não como N alarmes soltos.
- Padrão customizado via JavaScript, pra lógica de correlação que não cabe numa condição simples de trigger.
- Alteração automática de tag e severidade do evento com base na regra que casou.
- Fechamento automático de evento symptom (o "sintoma" que decorre de uma causa raiz já tratada), sem precisar de ação manual pra cada um.
- Anonimização, item que abre espaço pro Zabbix ser usado em cenário de correlação com dado sensível — inclusive uso citado pra detecção de fraude e SIEM, além do escopo tradicional de rede.
Cada regra tem três partes: o que capturar (filtro de evento), como agrupar (janela de tempo e lógica de agrupamento) e o que fazer quando casa (a operação — mudar tag, mudar severidade, suprimir, renomear o evento).
O que isso muda pra quem já briga com fadiga de alarme
Se você chegou até aqui vindo do post sobre fadiga de alarme, a lógica vai soar familiar: dependência de trigger pra suprimir sintoma, threshold por perfil, janela de confirmação. O que muda com o CEP é onde essa lógica mora. Hoje, boa parte disso é resolvida trigger por trigger, host por host — funciona, mas escala mal quando o parque cresce. O CEP move parte dessa responsabilidade pra um motor central de regras, que enxerga o evento depois que ele já foi gerado e decide o que fazer com ele antes de chegar no NOC — dedup, severidade, fechamento automático de sintoma, tudo num lugar só, com lógica JavaScript quando a regra simples não é suficiente.
Isso não substitui o trabalho de configurar trigger com threshold correto — continua sendo a base. Mas resolve o problema de correlação entre triggers e entre hosts de um jeito que dependência de trigger isolada não cobre bem: um rompimento de backbone que hoje dispara 40 alarmes de equipamentos downstream é candidato natural a virar uma regra de CEP com janela de tempo e agrupamento, em vez de 40 dependências configuradas manualmente.
O que fica de recomendação prática
O 8.0 ainda está no ciclo de lançamento — vale testar o CEP em ambiente de homologação antes de desenhar a arquitetura de alarme da operação em cima dele, já que é recurso novo e a documentação ainda está em formação. Mas o sinal mudou: não é mais "vamos ver se sai", é "já saiu, agora é validar no seu ambiente". Se sua operação lida com volume de evento que já estourou o que trigger dependency dá conta de organizar, esse é o motivo certo pra colocar o upgrade pro 8.0 no radar deste trimestre.
O NOC Geomap se conecta ao Zabbix que sua operação já usa, então nenhuma dessas mudanças no motor de evento exige trocar de ferramenta de mapa — só ganha em qualidade de sinal o que chega até ele. Se quiser trocar ideia sobre como preparar esse upgrade, fale com a gente.
Fontes: documentação oficial do Zabbix 8.0 — Event correlation e Hawatel — Zabbix 8.0 LTS: A new standard for monitoring and observability.