Quando o Auto Scaling gera uma tempestade de alertas: consolidando eventos Zabbix antes de notificar

Auto Scaling faz exatamente o que foi projetado para fazer: cria, substitui e remove instâncias conforme o estado do ambiente.

O problema aparece quando a monitoria interpreta cada consequência dessa movimentação como um incidente independente.

Uma troca normal de instâncias pode produzir uma sequência parecida com:

1
2
3
4
5
6
7

host novo detectado
agente ainda indisponível
instância reiniciada
update do evento
recovery
outro host entrando
outro host saindo

Se cada evento virar uma mensagem, o canal do NOC recebe uma tempestade justo durante uma operação que pode estar saudável.

Em uma automação real, a solução foi parar de pensar em evento isolado e começar a pensar em janela de Auto Scaling.

O Zabbix continua detectando cada evento #

A automação não tenta esconder eventos do Zabbix.

O receptor recebe o webhook e classifica o payload.

De forma simplificada:

1
2
3
4
5
6
7

Webhook Zabbix
     ↓
normalização
     ↓
classificação
  ↙    ↓     ↘
PROBLEM UPDATE RECOVERY

Eventos relacionados ao Auto Scaling são persistidos para processamento posterior.

Alarmes normais, fora desse contexto, podem continuar seguindo a política de notificação imediata.

Essa separação é importante: reduzir ruído de Auto Scaling não significa silenciar a monitoria inteira.

O conceito central é uma janela #

Em vez de avisar sobre cada instância individualmente, os eventos são associados a uma chave de janela temporal.

Conceitualmente:

1
2
3
4
5
6
7

10:01 host A entrou
10:03 host B reiniciou
10:04 update host A
10:06 recovery host A
10:08 host C entrou
        ↓
     JANELA X

Durante a janela, a automação acumula contexto.

Depois, outro workflow avalia o conjunto.

Isso muda a pergunta de:

“O host A gerou uma trigger?”

para:

“Depois que essa movimentação estabilizou, o grupo continua precisando de atenção?”

O estado fica persistido em PostgreSQL #

O fluxo usa tabelas para representar janelas, eventos e atualizações.

Não é apenas memória em um node do n8n.

Essa persistência permite manter informações como:

1
2
3
4
5
6
7
8

window_key
primeiro evento
último evento
processing
processing_started_at
final_sent
eventos relacionados
updates do operador

Isso também ajuda em reinício do workflow e concorrência.

Automação que depende exclusivamente de memória temporária costuma ficar difícil de explicar depois de uma falha.

O fechador roda separado do receptor #

Uma decisão que considero boa nesse desenho é separar duas responsabilidades.

Receptor #

Precisa ser rápido:

1
2
3
4

receber
classificar
persistir
responder

Fechador #

Pode trabalhar com contexto:

1
2
3
4
5
6

procurar janelas vencidas
assumir uma janela
consultar eventos
verificar estado atual do cloud
decidir se notifica
finalizar

Assim, receber um webhook do Zabbix não fica preso à análise completa do Auto Scaling.

Concorrência: FOR UPDATE SKIP LOCKED #

O workflow de fechamento versionado usa um claim atômico no PostgreSQL.

O núcleo do padrão é:

1
2
3
4
5
6
7

SELECT id
FROM operational_windows
WHERE final_sent = false
  AND close_after_at <= now()
ORDER BY close_after_at
LIMIT 5
FOR UPDATE SKIP LOCKED;

Depois a janela é marcada como em processamento.

Esse padrão resolve uma questão importante:

se duas execuções do worker acontecerem ao mesmo tempo, quem fica com a janela?

Com SKIP LOCKED, outro worker não precisa disputar o mesmo registro já assumido.

É uma forma simples de criar fila concorrente usando PostgreSQL sem introduzir um broker apenas para esse estágio.

Também existe recuperação de lock abandonado #

O fluxo não verifica apenas:

1

processing = false

Ele considera a possibilidade de um processamento ter começado e nunca terminado.

Conceitualmente:

1
2
3
4
5

processing não está ativo
OU
processing_started_at está vazio
OU
processing_started_at ficou antigo demais

Isso evita transformar uma execução interrompida em uma janela presa para sempre.

O evento histórico não basta: consultar o estado atual #

Talvez a parte mais importante do desenho seja esta.

Antes de decidir a mensagem final, o workflow consulta o estado atual do Auto Scaling na AWS por uma rotina operacional controlada.

A lógica passa a comparar:

1
2
3

o que aconteceu durante a janela
+
o que existe agora

Isso é muito mais útil do que tomar uma decisão apenas porque uma instância gerou uma trigger alguns minutos antes.

Auto Scaling é dinâmico.

Uma instância problemática de cinco minutos atrás pode já ter sido substituída e o grupo pode estar completamente saudável.

Nem toda janela termina em WhatsApp #

O workflow possui uma variável de decisão equivalente a:

1

should_send_whatsapp

O resultado depende do estado consolidado.

Em um caminho saudável, uma janela pequena pode ser finalizada silenciosamente.

Em outro caminho, um evento maior pode gerar apenas um resumo.

Quando a validação indica atenção, a mensagem pode trazer contexto mais detalhado.

Em termos conceituais:

1
2
3
4
5
6

janela fechou
   ↓
cloud saudável?
   ├─ sim + pouco ruído → finaliza silenciosamente
   ├─ sim + evento relevante → resumo curto
   └─ não → mensagem de atenção + contexto

O objetivo deixa de ser “enviar tudo”.

Passa a ser interromper o operador quando a informação realmente merece atenção.

Updates também entram na consolidação #

A automação não guarda apenas eventos automáticos.

Atualizações/comentários associados à janela também podem ser persistidos e incorporados ao fechamento.

Isso permite que a mensagem final carregue, quando aplicável, contexto de atendimento que surgiu durante a movimentação.

Mas existe um cuidado editorial e de segurança: nomes, comentários e identificadores operacionais precisam ser tratados como dados internos.

Falha no snapshot precisa virar estado explícito #

Outro bom detalhe do fluxo: se a consulta à AWS não puder produzir um snapshot válido, o workflow não deveria simplesmente considerar a janela saudável.

O estado correto é algo como:

1

validação final não concluída

E então orientar verificação manual.

Isso evita um falso negativo perigoso:

não consegui verificar, portanto está tudo bem.

Em automação operacional, ausência de evidência não é evidência de normalidade.

O fechamento precisa ser idempotente #

Depois da decisão, a janela é marcada como finalizada.

Esse estado é essencial para que o mesmo conjunto não seja reenviado a cada execução do scheduler.

Uma automação desse tipo precisa responder claramente:

1
2
3
4
5

esta janela já foi processada?
foi enviada?
foi silenciosa?
ficou presa?
falhou durante a validação?

Sem estado persistente, a deduplicação vira tentativa e erro.

O que eu monitoraria na própria automação #

Além dos alertas que ela processa, eu criaria métricas para o pipeline:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

janelas abertas
janelas aguardando fechamento
janelas em processing
processing acima do timeout
janelas fechadas silenciosamente
janelas notificadas
falhas no snapshot cloud
erros de banco
erros no gateway de mensagem
idade da janela mais antiga pendente

Quando uma automação existe para reduzir ruído, ela própria não pode falhar silenciosamente.

O padrão não é específico de Auto Scaling #

O mesmo raciocínio serve para vários cenários:

• rolling deployment;
• Kubernetes rescheduling;
• failover de banco;
• troca de nós;
• manutenção programada;
• reboot coordenado;
• autoscaling de workers;
• eventos correlacionados de rede.

O padrão geral é:

1
2
3
4
5
6

eventos individuais
→ buffer temporal
→ correlação
→ validação do estado atual
→ política
→ notificação seletiva

O que a fonte real comprova #

A implementação que originou este artigo possui dois workflows ativos e versionados:

• um receptor que classifica eventos de Auto Scaling, updates e recoveries e persiste o estado;
• um fechador agendado que faz claim de janelas, agrega eventos, consulta o estado atual do cloud, aplica política de envio e finaliza a janela.

O JSON versionado comprova também o uso de PostgreSQL com FOR UPDATE SKIP LOCKED no claim e caminhos distintos para envio ou fechamento silencioso.

A documentação mais recente informa mudanças posteriores à data de alguns exports. Por isso este artigo usa apenas a interseção que pode ser sustentada entre documentação e código versionado.

Não apresento aqui números de redução de alertas, economia de tempo ou ROI porque essas métricas ainda não foram medidas de forma reproduzível.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[ ] eventos têm chave de correlação
[ ] janela temporal está definida
[ ] receptor é separado do fechador
[ ] estado é persistente
[ ] claim de processamento é atômico
[ ] lock abandonado pode ser recuperado
[ ] estado atual da infraestrutura é validado
[ ] falha na validação não vira “saudável”
[ ] política define quando notificar
[ ] janela finalizada não é processada novamente
[ ] própria automação é monitorada

O principal aprendizado #

Monitoria boa não é a que envia mais mensagens.

É a que preserva todos os eventos técnicos, mas consegue entregar ao operador a quantidade certa de interrupções.

Em ambientes dinâmicos, especialmente com Auto Scaling, o evento individual explica o que aconteceu em um instante.

A janela consolidada, somada ao estado atual da infraestrutura, explica se alguém ainda precisa agir.