Voto a consenso nel monitoraggio uptime - perché ha senso

Il classico monitoraggio multi-region riduce i falsi negativi ma aumenta i falsi positivi. Il voto a consenso risolve entrambi. Una spiegazione didattica del pattern.

Il punto debole del monitoraggio single-region

Il monitoraggio single-region significa che il vostro checker viene eseguito in un'unica posizione. Se si verifica un problema di rete sul percorso tra questa posizione e il vostro server (BGP flap, modifica del routing, manutenzione dell'ISP), il monitor segnala DOWN anche se il server sta funzionando correttamente.

Questo è un falso positivo. Ricevete l'avviso, vi svegliate alle 3 di notte, aprite il laptop e scoprite che il sito funziona.

I falsi positivi sono dannosi per due motivi:

Alert fatigue. Se ricevete notifiche che si rivelano false, gradualmente iniziate a ignorarle. Anche quelle reali.
Perdita di fiducia nel monitoraggio. Il team smette di reagire agli avvisi perché "probabilmente è di nuovo BGP".

Il multi-region naïve risolve un problema, peggiora l'altro

Il modo comune per affrontare questo è il monitoraggio multi-region. Il checker viene eseguito da più posizioni e un avviso scatta ogni volta che una qualsiasi di esse segnala DOWN.

Questo migliora il rilevamento dei veri outage - quando il server è davvero irraggiungibile, non solo un checker va in tilt ma diversi. Bene.

Ma il problema dei falsi positivi peggiora. Con un solo checker avevate un certo tasso di falsi avvisi. Con tre checker è matematicamente più probabile che almeno uno di essi segnali falsamente DOWN. Ricevete più falsi avvisi, non meno.

Il voto a consenso risolve entrambi i lati

Il voto a consenso funziona diversamente: al primo segnale DOWN non scatta un avviso. Si interrogano prima le altre region. Se la maggioranza di esse segnala anche DOWN, è un vero outage. In caso contrario, è un'anomalia di rete in una region.

Pseudocodice:

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'

Esempio di scenario:

primary  -> DOWN  (un checker ha avuto un BGP flap)
region_a -> UP    (le altre region vedono il server normalmente)
region_b -> UP

Risultato: UP. Nessun avviso. Voce nel debug log.

E il contrario, un vero outage:

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

Risultato: DOWN. L'avviso parte tramite Telegram/email/webhook.

Tradeoff: latenza

Il voto a consenso ha un costo - su un segnale DOWN aggiunge alcuni secondi di latenza per interrogare le altre region. Per la maggior parte dei casi d'uso (monitoraggio uptime con intervallo di un minuto) è trascurabile. Per SLA estremamente rigorosi con tempo di rilevamento inferiore ai 30 secondi può essere un compromesso.

Quando il multi-region non ha senso

API interne su 192.168.x.x. Nessuno al di fuori della vostra rete può raggiungerle, quindi il multi-region da Internet non ha senso. Per la LAN usate un pattern pull-agent - l'agent viene eseguito nella vostra rete e invia i risultati tramite HTTPS.
App interna single-customer. Se la usano poche persone e voi siete uno di loro, saprete di un outage prima del monitoraggio.
Un servizio che gira solo in una region del mondo. Se il vostro servizio è solo per l'UE e lo vedete come DOWN dagli Stati Uniti, non è un falso positivo - è atteso.

Come lo facciamo in ePulz.io

ePulz.io ha il voto a consenso nell'architettura. gather_multiregion() e combine_consensus() in monitoring.py implementano il pattern descritto sopra. La soglia (quante region devono confermare DOWN) è configurabile tramite il parametro min_down.

Nella tabella Check ogni riga memorizza un campo consensus con CSV (ad esempio "primary:up,region_a:up,region_b:down"), così per il debug avete il record esatto di come è stata presa la decisione.

Per self-hosting di un worker in un'altra region, il pannello admin dispone di un generatore di bundle WireGuard - crea un tar.gz con la configurazione per un nuovo nodo worker e lo aggiunge a worker_urls.

Conclusione

Il voto a consenso non è una soluzione magica. Non vi darà zero falsi positivi e non vi salverà in un vero outage. Ma è un compromesso migliore del single-region (alta percentuale di falsi positivi durante le anomalie di rete) o del multi-region naïve (moltiplicazione dei falsi positivi).

Date un'occhiata a ePulz.io. 7 giorni di prova, 3 monitor, senza carta di credito.