Consensus voting in uptime monitoring - waarom het zinvol is

Klassieke multi-region monitoring vermindert false negatives, maar verhoogt false positives. Consensus voting lost beide op. Een educatieve uitleg van het pattern.

Het zwakke punt van single-region monitoring

Single-region monitoring betekent dat je checker op één locatie draait. Als er een netwerkprobleem optreedt op het pad tussen deze locatie en je server (BGP flap, routing-wijziging, ISP-onderhoud), meldt de monitor DOWN terwijl de server prima werkt.

Dit is een false positive. Je krijgt de melding, je wordt om 3 uur 's nachts wakker, je opent je laptop en ontdekt dat de site werkt.

False positives doen op twee manieren pijn:

Alert fatigue. Als je meldingen krijgt die niet blijken te kloppen, ga je ze geleidelijk negeren. Ook de echte.
Verlies van vertrouwen in monitoring. Het team reageert niet meer op alerts omdat "het waarschijnlijk gewoon weer BGP is".

Naïef multi-region lost één probleem op en maakt het andere erger

De gebruikelijke manier om dit aan te pakken is multi-region monitoring. De checker draait vanaf meerdere locaties en er gaat een alert af zodra een van hen DOWN meldt.

Dit verbetert de detectie van echte storingen - als de server werkelijk onbereikbaar is, valt niet één checker uit, maar meerdere. Prima.

Maar het probleem van false positives wordt erger. Met één checker had je een bepaald percentage valse alerts. Met drie checkers is het wiskundig waarschijnlijker dat er ten minste één onterecht DOWN meldt. Je krijgt meer valse alerts, niet minder.

Consensus voting lost beide kanten op

Consensus voting werkt anders: bij het eerste DOWN-signaal stuur je geen alert. Je vraagt eerst de andere regio's. Als de meerderheid van hen ook DOWN meldt, is het een echte storing. Zo niet, dan is het een netwerkanomalie in één regio.

Pseudocode:

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'

Voorbeeldscenario:

primary  → DOWN  (one checker had a BGP flap)
region_a → UP    (other regions see the server normally)
region_b → UP

Result: UP. No alert. Entry in debug log.

En het tegenovergestelde, een echte storing:

primary  → DOWN
region_a → DOWN
region_b → DOWN

Result: DOWN. Alert goes via Telegram/email/webhook.

Tradeoff: latency

Consensus voting heeft een prijs - bij een DOWN-signaal voegt het een paar seconden latency toe om andere regio's te bevragen. Voor de meeste use cases (uptime monitoring met een minutenniveau) is dat verwaarloosbaar. Voor extreem strikte SLA's met een detectietijd onder 30 seconden kan het een compromis zijn.

Wanneer multi-region geen zin heeft

Interne API's op 192.168.x.x. Niemand buiten je netwerk kan ze bereiken, dus multi-region vanaf het internet is zinloos. Gebruik voor LAN het pull-agent pattern - de agent draait in je netwerk en pusht resultaten via HTTPS.
Single-customer interne app. Als slechts een paar mensen die gebruiken en jij er een van bent, weet je van een storing eerder dan monitoring.
Een dienst die maar in één regio van de wereld draait. Als je dienst alleen voor de EU is en je ziet hem DOWN vanuit de VS, is dat geen false positive - het is verwacht.

Hoe wij het doen bij ePulz.io

ePulz.io heeft consensus voting in de architectuur. gather_multiregion() en combine_consensus() in monitoring.py implementeren het pattern hierboven. De drempel (hoeveel regio's DOWN moeten bevestigen) is configureerbaar via de parameter min_down.

In de Check-tabel slaat elke rij een veld consensus op met CSV (bijv. "primary:up,region_a:up,region_b:down"), zodat je voor debugging de exacte registratie hebt van hoe de beslissing tot stand kwam.

Voor self-hosting van een worker in een andere regio heeft het admin paneel een WireGuard bundle generator - die maakt een tar.gz met configuratie voor een nieuwe worker node en voegt deze toe aan worker_urls.

Conclusie

Consensus voting is geen magische oplossing. Het levert je geen nul false positives op en het redt je niet in een echte storing. Maar het is een beter compromis dan single-region (hoge false positives bij netwerkanomalieën) of naïef multi-region (vermenigvuldiging van false positives).

Bekijk ePulz.io. 7-daagse proefperiode, 3 monitors, geen creditcard.