Contexto
Tínhamos dois Alertmanagers em regiões diferentes — um em Virginia, outro em Ohio — atrás de um Prometheus global e de um único receptor no Slack. Quando um dos peers ficava degradado, a deduplicação falhava: cerca de 400 alertas duplicados por dia, a maioria notificações de resolved, aumentando o ruído operacional e a desconfiança no canal.
Diagrama de arquitetura
Cluster saudável
Os dois peers reconciliam estado dentro da janela de deduplicação.
Dois Alertmanagers, um Prometheus
Um único Prometheus faz scrape e envia alertas para os dois Alertmanagers, um em cada região (Virginia e Ohio).
Gossip reconcilia a tempo
Com push/pull a cada 60s e sem perda de broadcast, os dois peers convergem para o mesmo estado antes da janela de dedup fechar.
Slack recebe uma notificação
O Alertmanager de Virginia assume a notificação; Ohio reconhece o mesmo alerta via gossip e suprime o próprio envio.
Investigação
Conduzi a investigação desde o primeiro alerta duplicado, depurando os dois nós em paralelo e reproduzindo o problema num ambiente isolado. A primeira hipótese foi latência de rede entre as regiões: se o gossip demorasse demais para atravessar a VPN entre Virginia e Ohio, os dois nós decidiriam notificar antes de se reconhecerem.
Testei essa hipótese primeiro — media round-trip entre os peers, comparava com a janela de deduplicação configurada. Não explicava o impacto: a latência medida era pequena demais para, por si só, causar 400 duplicados por dia.
Hipóteses testadas
| Hipótese | Teste | Resultado |
|---|---|---|
| Latência entre regiões | Round-trip via VPN medido e comparado à janela de dedup | Latência pequena demais para explicar o volume — descartada |
| Reconciliação de estado via Gossip | Broadcast incremental perdido + janela de push/pull vs. peer timeout | Estado não reconciliava a tempo — causa raiz |
Com a hipótese de latência descartada, aprofundei na comunicação Gossip entre os dois Alertmanagers.
Diagrama de arquitetura
Peer degradado
Um broadcast Gossip incremental se perde e o estado não reconcilia a tempo.
Mesma topologia, peer degradado
Nada mudou na topologia. O que muda é a confiabilidade da rede entre as duas regiões.
push/pull 60s, peer timeout 15s
Quando um broadcast Gossip incremental se perde, o peer timeout de 15s expira antes do próximo ciclo de push/pull completo (60s) reconciliar o estado.
Slack recebe dois avisos
Cada Alertmanager decide reenviar a notificação de resolved sem conhecer o estado atualizado do outro peer — duplicação, cerca de 400 alertas por dia.
A configuração padrão usava push/pull interval de 60s e peer timeout de 15s. O push/pull é a sincronização completa de estado via TCP; o peer timeout é a janela de espera que a deduplicação usa antes de decidir que o peer não respondeu. Com push/pull maior que o peer timeout, um broadcast Gossip incremental perdido não tinha chance de ser corrigido pelo próximo ciclo completo antes da janela de dedup se esgotar — e o nó decidia reenviar a notificação de resolved sem conhecer o estado atualizado do outro peer.
Ação
Ajuste de intervalos do cluster
Decisão
Reduzir o push/pull interval de 60s para 10s, mantendo o peer timeout em 15s.
Motivo
O push/pull precisa ser menor que o peer timeout para garantir que o estado reconcilie dentro da janela de dedup, mesmo quando um broadcast incremental se perde.
Consequência
Mais tráfego de sincronização entre os peers, em troca de convergência de estado dentro da janela esperada.
- --cluster.pushpull-interval=60s
+ --cluster.pushpull-interval=10s
--cluster.peer-timeout=15sO fix foi levado para produção como patch direto na configuração do cluster.
Diagrama de arquitetura
Pós-fix
push/pull cai para 10s; peer timeout permanece em 15s.
Mesma topologia, novo intervalo
Nenhum nó, região ou receptor mudou. Só o intervalo de sincronização de estado do cluster.
10s de push/pull, 15s de peer timeout
Com push/pull mais frequente que o peer timeout, mesmo um broadcast incremental perdido é coberto pelo próximo ciclo completo antes da janela de dedup fechar.
Slack volta a receber uma notificação
Duplicados caem de ~400/dia para 150–200/dia. O que resta não é mais dedup: é ruído legítimo de variação de rede dos clientes.
Resultado
Os alertas duplicados caíram de aproximadamente 400 por dia para 150–200 por dia. Antes de comemorar a redução inteira como mérito do fix, separei o que sobrou: o residual é o fluxo padrão de alertas abertos pela variação real de rede dos clientes — não duplicação por falha de dedup. Atribuir esse ruído ao fix teria inflado o resultado e escondido um problema diferente.
Aprendizado
Passei a validar HA também sob falha, não só no caminho feliz:
Como valido HA de cluster agora
Um cluster saudável só prova o happy path. HA de verdade precisa convergir quando os peers estão degradados — e medir o resultado exige separar o sinal que o fix resolveu do ruído que nunca foi problema de dedup.
Glossário
- Gossip protocol
- Protocolo pelo qual os peers do Alertmanager trocam estado entre si, sem depender de um coordenador central.
- Push/pull interval
- Intervalo em que cada peer sincroniza seu estado completo com os demais via TCP, complementando os broadcasts incrementais do Gossip.
- Peer timeout
- Janela de espera que a deduplicação usa antes de decidir que um peer não respondeu ou não reconciliou o estado a tempo.
- Janela de deduplicação
- Intervalo dentro do qual os peers precisam concordar sobre o estado de um alerta para evitar que mais de um notifique o mesmo evento.