Alertas, ações e webhooks

Alerta é um pipeline, não um botão

Uma trigger gera um evento; uma Action avalia se aquele evento deve provocar operações; a Operation define envio, comando ou outra ação; a escalation determina o momento e a repetição; o media type entrega a mensagem; e o usuário precisa possuir mídia configurada e permissão suficiente sobre o host. Quando uma notificação não chega, esse pipeline fornece uma sequência objetiva de diagnóstico.

Nem toda Action nasce de uma trigger

O Zabbix 7.4 possui Actions para eventos de triggers, Services, Network Discovery, Autoregistration e eventos internos. Cada fonte possui condições e operações próprias. Trigger Actions tratam mudanças OK↔PROBLEM; Service Actions trabalham com mudanças de status de Services; Discovery e Autoregistration automatizam onboarding; Internal Actions podem reagir a itens unsupported ou triggers em estado desconhecido.

Condição boa reduz ruído antes da primeira mensagem

Uma Action deve selecionar o menor conjunto possível de eventos que realmente exigem aquela resposta. Em vez de “severity >= Warning para tudo”, combine severidade, host group, tag, nome, período e escopo conforme o processo. Actions pequenas e especializadas são mais fáceis de auditar que uma Action universal com dezenas de exceções.

A Operation é a resposta executada

Operations podem enviar mensagens e, em cenários permitidos, executar comandos ou outras operações específicas da fonte do evento. Em Trigger Actions, operações normais acontecem durante o problema; Recovery Operations são executadas quando o evento é resolvido; Update Operations podem reagir a atualizações como acknowledgment, mudança de severidade, comentário ou outras alterações suportadas.

Tempo é parte da política de incidente

Escalations permitem avisar imediatamente, repetir mensagens, atrasar notificações, acionar um grupo superior e executar respostas após determinado tempo. A lógica é baseada em steps. O step 1 representa ações imediatas; steps seguintes obedecem a durações. No Zabbix 7.4, a duração mínima de um escalation step é 60 segundos.

Canal de entrega é infraestrutura crítica

Media types suportados incluem Email, SMS, Custom script e Webhook. Um canal só funciona quando três peças estão corretas: a Operation envia para alguém, o media type está configurado/ativo e o usuário possui uma mídia correspondente habilitada. Falha em qualquer uma delas impede a entrega.

Destinatário sem acesso pode não ser notificado

Para operações de envio, o usuário ou grupo precisa possuir pelo menos permissão de leitura sobre o host envolvido. Isso é um detalhe operacional importante: adicionar um endereço de email não garante notificação se a política de acesso do usuário não permite visualizar o objeto que gerou o evento.

A mensagem deve carregar contexto suficiente para agir

Media types possuem templates de mensagem por fonte de evento e modo: problema, recuperação e atualização. Um template consistente evita que cada Action invente um formato. A mensagem deve responder rapidamente: o quê, onde, desde quando, impacto, severidade, contexto, estado atual e qual o próximo passo.

Transforme o evento em uma mensagem contextual

Mensagens podem usar macros de evento, host, trigger, item, usuário e tags. Tags são especialmente valiosas porque transportam contexto operacional como site, operadora, serviço, circuito e escopo. Evite despejar todas as macros disponíveis: uma mensagem boa apresenta informação selecionada, não um dump do banco.

O fim do incidente também é informação

Recovery Operations devem informar normalização quando isso reduz trabalho humano. O destinatário precisa saber qual problema recuperou, horário da recuperação e duração total. Para integrações com tickets, a recuperação pode atualizar ou encerrar o registro externo em vez de simplesmente criar uma segunda notificação desconectada.

Acknowledgment faz parte do ciclo operacional

Update Operations podem comunicar que alguém reconheceu, comentou ou alterou um evento. Em operações maduras, isso permite separar “evento detectado”, “incidente assumido”, “escalado”, “resolvido tecnicamente” e “fechado”. Nem todo update precisa gerar mensagem; escolha os que representam mudança real de responsabilidade ou estado.

A melhor notificação é aquela que não precisou ser enviada

Antes de criar mais canais, corrija trigger, histerese, dependências, manutenção, correlação e severidade. Um sistema que gera mil eventos ruins continuará ruim no email, no chat e no telefone. Alerting deve ser a última etapa de uma cadeia de sinais já qualificada.

Equipe certa é melhor que lista grande

Direcione banco para DBAs, conectividade para NOC, aplicação para time responsável e segurança para equipe adequada. Tags como team, service, scope e criticality podem apoiar esse roteamento. Alertar todos para tudo aumenta tempo de resposta porque ninguém sabe quem realmente possui a ação.

Disponibilidade do canal precisa refletir disponibilidade da equipe

User media pode ter períodos ativos e filtros de severidade. Use isso para separar expediente e plantão, mas mantenha a política simples. Se a organização possui escala externa de on-call, avalie integrar o Zabbix com essa fonte de verdade em vez de manter calendários divergentes manualmente em vários usuários.

Repetir sem mudar contexto apenas produz fadiga

Escalations permitem repetir mensagens enquanto o problema permanece aberto. Repetição faz sentido quando cada step representa nova expectativa: lembrete, mudança de responsável, acionamento gerencial ou procedimento adicional. Reenviar a mesma mensagem a cada cinco minutos sem estratégia é ruído automatizado.

Automação corretiva precisa de barreiras fortes

Actions podem disparar comandos em cenários permitidos. Isso transforma monitoramento em sistema de atuação. Use apenas para procedimentos idempotentes, testados, limitados por contexto e com observabilidade. Reiniciar serviço automaticamente pode ser útil; reiniciar indefinidamente um serviço com causa raiz desconhecida apenas mascara o problema.

Webhook é uma integração programável por HTTP

O media type Webhook usa JavaScript para realizar chamadas HTTP e integrar sistemas externos como chats, mensageria e helpdesk. É possível importar integrações oficiais disponibilizadas pelo Zabbix ou criar uma própria. O webhook deve tratar autenticação, timeout, resposta HTTP, erros e atualização do objeto remoto.

Comece por integração mantida quando existir

O ecossistema oficial disponibiliza webhooks para diversas ferramentas. Antes de escrever um do zero, verifique se existe integração mantida compatível com sua necessidade. Isso reduz custo de manutenção e normalmente já implementa fluxo de criação, atualização e resolução.

Ticket ID é estado, não apenas texto

Webhooks mais avançados podem guardar IDs de ticket ou mensagem em tags do evento para localizar o objeto externo em updates e recovery. A documentação alerta para não usar o mesmo webhook em múltiplas Actions que possam disparar para o mesmo problema usando a mesma tag de armazenamento, pois o valor resultante pode ficar indefinido.

Eventos internos exigem atenção especial com webhook

Quando um webhook é usado em Actions de eventos internos, a documentação oficial exige mensagem customizada na Operation. Sem isso, a notificação pode não ser enviada. Esse tipo de detalhe deve estar no runbook do media type, não depender da memória do administrador.

Teste media type isoladamente antes de testar a Action

O frontend permite testar media types. Faça o teste em camadas: primeiro media type, depois usuário/mídia, depois Action, depois evento real. Isso evita investigar trigger, Action e SMTP/API simultaneamente quando o problema é apenas credencial ou endpoint.

Webhook e media type carregam segredos operacionais

Tokens, senhas SMTP, URLs privadas e chaves de integração devem ser tratados como segredos. Use macros secretas/Vault quando apropriado, restrinja permissões e evite valores sensíveis em logs ou mensagens de erro. O sistema de alertas frequentemente possui acesso a ferramentas críticas — helpdesk, chat corporativo e automação — e deve ser protegido como integração privilegiada.

Um evento não deve criar dez tickets iguais

Integrações de helpdesk precisam distinguir create, update e resolve. Use event ID/problem ID e tags de estado para impedir duplicidade. Retries devem ser seguros: repetir a mesma chamada após timeout não deveria criar outro incidente se o primeiro request já tiver sido processado.

O próprio alerting precisa ser monitorado

Falha de SMTP, webhook, script ou fila de alerts pode deixar o NOC cego enquanto o Zabbix continua detectando problemas. Monitore processos de alerter, logs, filas e erros de media type. Uma operação madura testa periodicamente o caminho completo de notificação, não apenas a coleta.

Do problema ao destinatário

TRIGGER / SERVICE / DISCOVERY / INTERNAL EVENT
                    │
                    ▼
                  EVENT
                    │
                    ▼
                 ACTION
          ┌─────────┴─────────┐
          │                   │
      CONDITIONS          OPERATIONS
                              │
                              ▼
                         ESCALATION
                     step 1 / 2 / 3...
                              │
                              ▼
                         MEDIA TYPE
                 email / SMS / script / webhook
                              │
                              ▼
                      USER / USER GROUP
                              │
                              ▼
                         DESTINATION

Separe por intenção operacional

Exemplo de escalonamento orientado por responsabilidade

PROBLEMA HIGH / DISASTER

STEP 1 — imediato
→ NOC
→ chat operacional

STEP 2 — após 10 min ainda aberto
→ repetir para NOC
→ acionar responsável técnico

STEP 3 — após 30 min ainda aberto
→ responsável técnico + liderança

RECOVERY
→ mesmos responsáveis recebem normalização

UPDATE
→ acknowledgment relevante pode registrar responsável

Mensagem operacional, não dump técnico

[HIGH] WAN indisponível — POP Centro

Host: rtr-rj-centro-01
Problema: Link Operadora A indisponível
Início: 14:32:18
Operadora: Operadora A
Circuito: CIR-A-001
Site: RJ-Centro
Serviço: Internet
Severidade: High

Último estado:
ICMP: down
BGP: down
Interface física: up

Evento:
{EVENT.ID}

Ação inicial:
Validar circuito, BGP e ocorrência massiva da operadora.

Create → Update → Resolve

PROBLEM EVENT
    │
    ├─ POST /tickets
    │      └─ retorna ticket_id = INC-48321
    │
    ├─ armazenar referência em tag/estado da integração
    │
UPDATE / ACK
    │
    ├─ PATCH /tickets/INC-48321
    │
RECOVERY
    │
    └─ PATCH /tickets/INC-48321
           status = resolved

Estrutura mínima de uma integração própria

// Pseudocódigo conceitual

params = JSON.parse(value);

validate(params);

request = new HttpRequest();
request.addHeader('Authorization: Bearer ' + params.token);
request.addHeader('Content-Type: application/json');

if (params.event_value === '1') {
    // criar/atualizar incidente
}

if (params.event_value === '0') {
    // resolver incidente
}

response = request.post(params.url, JSON.stringify(payload));

if (request.getStatus() < 200 || request.getStatus() >= 300) {
    throw 'HTTP error';
}

return JSON.stringify({
    tags: {
        external_id: id_retornado
    }
});

O código acima é intencionalmente conceitual. Cada API possui autenticação, payload, métodos de update e semântica de retry próprios.

Severidade deve mudar a resposta, não apenas a cor

“O problema apareceu, mas ninguém recebeu”

Alerting que parece eficiente, mas escala mal

Action de incidente crítico com escalation

Teste o ciclo inteiro

Antes de ativar uma Action

Base factual

Conteúdo construído a partir da documentação oficial Zabbix 7.4 sobre Actions, Conditions, Operations, Recovery Operations, Update Operations, Escalations, Media Types, Email, Scripts, Webhooks, permissões e message templates. A arquitetura de roteamento, matriz de severidade, modelo de mensagem, fluxo stateful de ticket, laboratórios e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Zabbix 7.4 suporta OAuth 2.0 para SMTP em media types, inclusive fluxos facilitados para Gmail e Office 365. Trate credenciais, tokens e webhooks como segredos.