Votação por consenso na monitorização de uptime - porque faz sentido

A monitorização multi-region clássica reduz os falsos negativos mas aumenta os falsos positivos. A votação por consenso resolve ambos. Uma análise didática do padrão.

O ponto fraco da monitorização single-region

A monitorização single-region significa que o seu checker é executado num único local. Se ocorrer um problema de rede no caminho entre esse local e o seu servidor (BGP flap, alteração de routing, manutenção do ISP), o monitor reporta DOWN apesar de o servidor estar a funcionar.

Isto é um falso positivo. Recebe o alerta, acorda às 3 da manhã, abre o portátil e descobre que o site está a funcionar.

Os falsos positivos são prejudiciais por duas razões:

Alert fatigue. Se receber notificações que se revelam falsas, gradualmente começa a ignorá-las. Mesmo as verdadeiras.
Perda de confiança na monitorização. A equipa deixa de reagir aos alertas porque "provavelmente é o BGP outra vez".

O multi-region ingénuo resolve um problema, piora o outro

A forma comum de abordar isto é a monitorização multi-region. O checker corre a partir de vários locais e um alerta dispara sempre que qualquer um deles reporte DOWN.

Isto melhora a deteção de outages reais - quando o servidor está mesmo inacessível, não é apenas um checker que falha, mas vários. Bom.

Mas o problema dos falsos positivos piora. Com um checker tinha uma certa taxa de falsos alertas. Com três checkers é matematicamente mais provável que pelo menos um deles reporte DOWN falsamente. Recebe mais falsos alertas, não menos.

A votação por consenso resolve ambos os lados

A votação por consenso funciona de forma diferente: ao primeiro sinal DOWN não dispara um alerta. Pergunta primeiro às outras regions. Se a maioria delas também reportar DOWN, é um outage real. Caso contrário, é uma anomalia de rede numa region.

Pseudocódigo:

result = check_http(monitor)  # primary region
if result.status == 'down':
    secondary_results = check_from_other_regions(monitor)
    if secondary_results:
        # Default rule: 2 of 3 regions must agree on DOWN
        if count_down(secondary_results) + 1 >= 2:
            result.status = 'down'
        else:
            result.status = 'up'
            result.note = 'consensus mismatch'

Exemplo de cenário:

primary  -> DOWN  (um checker teve um BGP flap)
region_a -> UP    (as outras regions veem o servidor normalmente)
region_b -> UP

Resultado: UP. Sem alerta. Entrada no debug log.

E o oposto, um outage real:

primary  -> DOWN
region_a -> DOWN
region_b -> DOWN

Resultado: DOWN. O alerta segue via Telegram/email/webhook.

Tradeoff: latência

A votação por consenso tem um custo - num sinal DOWN acrescenta alguns segundos de latência para consultar as outras regions. Para a maioria dos casos de uso (monitorização de uptime com intervalo de um minuto) é desprezável. Para SLAs extremamente rigorosos com tempo de deteção inferior a 30 segundos pode ser um compromisso.

Quando o multi-region não faz sentido

APIs internas em 192.168.x.x. Ninguém fora da sua rede consegue alcançá-las, portanto o multi-region a partir da Internet não tem significado. Para a LAN use um padrão pull-agent - o agent corre na sua rede e envia os resultados por HTTPS.
App interna de cliente único. Se apenas algumas pessoas a usam e o senhor é uma delas, saberá de um outage antes da monitorização.
Um serviço que apenas corre numa region do mundo. Se o seu serviço é apenas para a UE e o vê como DOWN a partir dos EUA, não é um falso positivo - é o esperado.

Como o fazemos em ePulz.io

ePulz.io tem votação por consenso na arquitetura. gather_multiregion() e combine_consensus() em monitoring.py implementam o padrão acima. O threshold (quantas regions têm de confirmar DOWN) é configurável através do parâmetro min_down.

Na tabela Check cada linha guarda um campo consensus com CSV (por exemplo "primary:up,region_a:up,region_b:down"), portanto para depuração tem o registo exato de como a decisão foi tomada.

Para self-hosting de um worker noutra region, o painel admin tem um gerador de bundle WireGuard - cria um tar.gz com a configuração para um novo nó worker e adiciona-o a worker_urls.

Conclusão

A votação por consenso não é uma solução mágica. Não lhe dará zero falsos positivos e não o salvará num outage real. Mas é um compromisso melhor do que o single-region (elevada taxa de falsos positivos durante anomalias de rede) ou o multi-region ingénuo (multiplicação de falsos positivos).

Veja o ePulz.io. 7 dias de período experimental, 3 monitores, sem cartão de crédito.