Monitorização multirregião: como eliminar as quedas falso-positivas

Os falsos alarmes ensinam a equipa a ignorar os alertas. Um cross-check multirregião só sinaliza uma queda quando várias sondas independentes a confirmam.

Porque é que a monitorização de região única mente

A monitorização clássica tem uma única posição de observação (um servidor ou uma região cloud). Quando essa sonda não recebe resposta, reporta uma queda. A causa, porém, pode ser qualquer uma das seguintes:

Um problema na própria rede da sonda (route flap, um problema de peering do provider dela)
Um glitch de DNS de curta duração do lado da sonda
Uma queda geograficamente limitada (um edge de CDN caiu num país)
Rate limiting ou um bloqueio de IP do lado da tua infraestrutura

Do ponto de vista dos utilizadores reais, o site pode estar perfeitamente bem - apenas inacessível para um host de monitorização específico.

A consequência: alert fatigue

Uma equipa que recebe 3 notificações de "queda" por semana, das quais 2 são falsos alarmes (falso-positivos), deixa gradualmente de reagir. Quando depois chega uma queda real, a reação atrasa-se ou ninguém repara. Este fenómeno chama-se alert fatigue (fadiga de alertas) e está bem documentado na literatura devops.

O objetivo é a melhor relação sinal-ruído (signal-to-noise ratio) possível. É melhor 1 notificação por mês que é sempre real do que 10 notificações das quais 7 são ruído.

O padrão multirregião: consenso de N sondas

O princípio:

Tens 3 nós worker em 3 cidades (primary em Liptovský Hrádok, eu2 em Liptovský Mikuláš, eu1 em Bratislava). O limiar predefinido = 2 de 3, o que dá um consenso real (não unânime). A arquitetura suporta qualquer número de nós; ao expandir, juntam-se ao mecanismo de consenso existente.
Em cada intervalo, todas as sondas testam o endpoint em paralelo.
Juntas o resultado: uma queda é confirmada se M de N sondas a reportarem (tipicamente M = 2 ou mais).
A falha de uma única sonda não dispara um alarme - se uma sonda reporta "down" mas as outras reportam "up", o sistema mantém-se no estado UP.

Trata-se do chamado consensus algorithm (algoritmo de consenso), semelhante ao Raft ou Paxos - a decisão é tomada por maioria de votos.

Configuração prática

No painel de administração do ePulz.io, o multirregião ativa-se com um único interruptor e configura-se através de:

Regiões ativas - a lista de workers, tipicamente 3-5
Limiar de consenso - quantas regiões têm de dizer DOWN (predefinido: 2)
Worker token - um segredo partilhado (shared secret) entre o servidor principal e os workers para verificação

Em cada verificação, o servidor principal contacta todos os workers em paralelo através da API HTTP. Um worker executa um teste HTTP, TCP ou ping local e devolve o resultado. O servidor principal avalia o consenso e só escala o alerta quando o limiar é ultrapassado.

Trade-offs

Prós:

Muito menos falsos alarmes
Visualização geográfica - vês de que regiões o site não funciona
Deteção de quedas regionais (problema com um PoP da Cloudflare, routing defeituoso num ISP)

Contras:

Latência ligeiramente maior entre a queda real e o alerta (espera-se pelo consenso de várias fontes)
Maiores exigências de infraestrutura e um plano de preços superior
Disponibilidade dos workers - se metade dos workers estiver, ela própria, inacessível, o limiar pode não ser alcançável (a solução é um limiar dinâmico = M das sondas atualmente ativas)

Exemplo de cálculo de consenso

Configuração de 3 nós worker realmente implementados: primary em Liptovský Hrádok (SK), eu2 em Liptovský Mikuláš (SK), eu1 em Bratislava (SK), limiar = 2.

Cenário	primary (Liptov)	eu1 (Bratislava)	eu2 (Liptov)	Alerta?
Tudo OK	UP	UP	UP	Não
BGP flap entre Liptov e o teu hosting	DOWN	UP	UP	Não (1 de 3)
Falha de HW da máquina primary	DOWN	UP	DOWN	Sim (2 de 3)
Queda real do teu servidor	DOWN	DOWN	DOWN	Sim

Como implementar os teus próprios workers

Um worker é um serviço simples que recebe tarefas de verificação por HTTPS, executa o teste e devolve o resultado. O ePulz.io suporta workers próprios através de um túnel WireGuard, pelo que podem correr em qualquer VPS sem IP público e comunicar com o servidor principal por um túnel cifrado.

Configurar um único worker leva, na prática, cerca de 10 minutos (apt install wireguard, copiar a config do peer, systemctl enable). Obténs assim posições de observação verdadeiramente independentes, que combinam diversidade geográfica (cidades diferentes) com redundância de hardware (máquinas diferentes na mesma cidade).

Conclusão

A monitorização multirregião não é apenas um chavão de marketing. É um padrão de engenharia concreto (quórum, ou consenso) que leva a monitorização do nível "vejo o que uma posição de rede vê" ao nível "vejo o que a internet vê". Para aplicações de negócio críticas, é hoje o standard.

Elimina os alertas falso-positivos

Cross-check multirregião nos planos base (gerido de forma centralizada). 7 dias grátis.

Iniciar monitorização →