Transformando alertas brutos do Zabbix em incidentes acionáveis com n8n
Como uma automação usa Zabbix API, filtro por idade, deduplicação, contexto visual, TTS e n8n para transformar alarmes persistentes em notificações acionáveis.
Um alerta existir no Zabbix não significa que alguém abriu o dashboard, entendeu o contexto e começou a tratar o problema.
Para alarmes persistentes, construí uma segunda camada de notificação com este fluxo:
| |
A ideia não é substituir o Zabbix.
É transformar um evento que já existe no monitoramento em uma mensagem que chega com contexto suficiente para provocar ação.
O problema de encaminhar alerta bruto #
Mandar diretamente o texto da trigger para outro canal costuma apenas mover o ruído.
Algo como:
| |
pode ser tecnicamente correto, mas ainda exige que alguém:
- reconheça o host;
- abra o Zabbix;
- encontre o problema;
- veja há quanto tempo está ativo;
- descubra se já recebeu o mesmo alerta antes.
A automação tenta reduzir essa distância.
O filtro por idade evita reagir a todo pico #
O projeto foi desenhado para procurar alarmes relevantes que permanecem ativos por uma janela mínima.
Na implementação que serviu de fonte, a lógica trabalha com alarmes persistentes — por exemplo, problemas que continuam ativos por dezenas de minutos — antes de acionar a camada contextual.
Isso evita transformar todo spike curto em uma mensagem de WhatsApp.
A janela exata não deve ser universal. Cada trigger tem SLA e comportamento próprios.
O que importa é a separação:
| |
Deduplicação é obrigatória #
Um workflow consultado a cada poucos minutos não pode enviar a mesma notificação em cada execução.
Por isso o projeto registra o evento e controla o estado de envio.
A lógica é baseada em deduplicação persistente: o mesmo problema é reconhecido como o mesmo problema em execuções posteriores.
Isso permite implementar políticas como:
| |
Sem isso, automação de incidente vira gerador de spam.
O screenshot reduz uma ida ao dashboard #
A automação usa navegador headless com uma conta dedicada de monitoria para gerar uma captura visual relacionada ao problema.
Isso não substitui investigação no Zabbix.
Mas permite que a pessoa receba, junto da mensagem, uma fotografia do contexto visual que normalmente teria de abrir manualmente.
A conta usada por automação deve ter apenas as permissões necessárias para leitura.
TTS local cria um canal adicional sem enviar texto para um serviço de voz externo #
O áudio é gerado localmente com Piper TTS.
Fluxo conceitual:
| |
Isso é útil quando a mensagem precisa chamar atenção em um canal onde texto pode passar despercebido.
Também mantém a geração de voz dentro da infraestrutura controlada.
IA entra como resumo, não como fonte da verdade #
A IA pode ajudar a transformar campos técnicos em uma mensagem mais legível.
Mas o evento, severidade, duração e estado continuam vindo do Zabbix/API.
Eu separo assim:
| |
A IA não deve inventar causa raiz para um alerta.
Se a trigger diz “latência alta”, a mensagem pode explicar que existe latência alta e há quanto tempo. Não deve concluir “o banco está saturado” sem evidência adicional.
Onde o n8n ajuda #
n8n funciona bem como camada de orquestração porque conecta etapas diferentes sem colocar toda a lógica em um único script.
No projeto, ele participa do fluxo de automação/entrega, enquanto componentes auxiliares fazem tarefas como consulta, screenshot e TTS.
Isso permite manter responsabilidades separadas:
| |
Um evento precisa de identidade estável #
Para deduplicar, é necessário definir uma chave que represente o incidente.
Ela pode ser derivada de identificadores do próprio Zabbix, desde que o modelo preserve a noção de “mesmo problema”.
Evitaria usar apenas o texto da trigger, porque:
- texto pode mudar;
- hosts diferentes podem gerar mensagens iguais;
- macros podem produzir pequenas variações.
O importante é que a chave seja determinística e não contenha segredo.
O que eu colocaria na mensagem #
Uma mensagem acionável pode ter:
| |
O objetivo não é colocar o dashboard inteiro no WhatsApp.
É dar ao operador contexto suficiente para decidir se precisa abrir o runbook imediatamente.
Falha da automação também precisa ser observável #
Existe uma ironia perigosa em automação de monitoramento: ela pode falhar silenciosamente.
Eu monitoraria pelo menos:
| |
Se o pipeline não entrega nada durante um incidente, deve ser possível saber se foi porque nenhum evento passou pelo filtro ou porque a própria automação quebrou.
Segurança do fluxo #
Alguns cuidados são indispensáveis:
- conta de Zabbix dedicada e read-only quando possível;
- tokens fora do workflow versionado;
- credencial do gateway fora do Git;
- screenshot sem páginas que exponham segredos;
- logs sem tokens/headers de autenticação;
- retenção controlada de imagens e áudio;
- deduplicação sem armazenar payload sensível desnecessário.
O que a implementação existente prova #
O projeto publicado no próprio CastroTI documenta uma automação com:
- Zabbix API;
- filtro por idade/relevância;
- deduplicação persistente;
- resumo contextual;
- TTS local com Piper;
- screenshot via navegador headless;
- n8n;
- envio por gateway/API de WhatsApp;
- conta dedicada de monitoria para contexto visual.
Esse conjunto sustenta o artigo sem precisar atribuir a automação a um cliente específico.
Um desenho reproduzível #
| |
Checklist #
| |
O principal aprendizado #
Automação de alertas não deveria fazer o Zabbix falar mais alto.
Ela deveria fazer o alerta chegar mais útil.
O ganho aparece quando a mensagem deixa de ser apenas “há um problema” e passa a carregar duração, contexto, mídia e deduplicação suficientes para alguém decidir o próximo passo sem começar do zero.
Me chama.
Manda o contexto, os sintomas e o que já foi testado. Bora organizar as evidências antes de sair mexendo.