Consensus voting v uptime monitoringu - proč dává smysl

Slabé místo single-region monitoringu

Single-region monitoring znamená, že váš checker běží v jedné lokaci. Pokud mezi touto lokací a vaším serverem dojde k síťovému problému (BGP flap, routing change, údržba ISP), monitor nahlásí DOWN, přestože server je v pořádku.

Jde o false positive. Dostanete alert, vzbudíte se ve tři ráno, otevřete laptop a zjistíte, že stránka funguje.

False positives škodí ze dvou důvodů:

1. Alert fatigue. Pokud dostáváte notifikace, které se ukážou jako nepravdivé, postupně je začnete ignorovat. I ty skutečné.
2. Ztráta důvěry v monitoring. Tým přestane reagovat na alerty, protože "to bude zase jen BGP".

Naivní multi-region řeší jeden problém, zhoršuje druhý

Běžný způsob, jak tento problém řešit, je multi-region monitoring. Checker běží z více lokací a alert se odešle pokaždé, když kterákoli z nich nahlásí DOWN.

Tím se zlepší detekce skutečných výpadků: když je server opravdu nedostupný, nezhasne jen jeden checker, ale hned několik. To je v pořádku.

Jenže problém s false positives se tím zhorší. U jednoho checkeru jste měli určitý poměr falešných alertů. U tří checkerů je matematicky pravděpodobnější, že alespoň jeden z nich falešně nahlásí DOWN. Výsledkem je více falešných alertů, ne méně.

Consensus voting řeší obě strany problému

Consensus voting funguje jinak: při prvním DOWN signálu se alert neodešle. Nejdřív se systém zeptá ostatních regionů. Pokud většina z nich také hlásí DOWN, jde o skutečný výpadek. Pokud ne, jde jen o síťovou anomálii v jednom regionu.

Pseudokód:

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'

Příklad situace:

primary  → DOWN  (jeden checker měl BGP flap)
region_a → UP    (ostatní regiony vidí server normálně)
region_b → UP

Výsledek: UP. Žádný alert. Záznam v debug logu.

A naopak při skutečném výpadku:

primary  → DOWN
region_a → DOWN
region_b → DOWN

Výsledek: DOWN. Alert jde přes Telegram/email/webhook.

Tradeoff: latence

Consensus voting má svou cenu: při DOWN signálu přidá pár sekund latence navíc, než se stihnou provést dotazy do dalších regionů. U většiny use-caseů (uptime monitoring s minutovým intervalem) je to zanedbatelné. U extrémně přísných SLA s detection time pod 30 sekund už může jít o citelný kompromis.

Kdy je multi-region nesmyslný

• Interní API na 192.168.x.x. Nikdo kromě vaší sítě se tam nedostane, takže multi-region z internetu nemá smysl. Pro LAN použijte pull-agent pattern: agent běží ve vaší síti a výsledky posílá ven přes HTTPS.
• Single-customer interní aplikace. Pokud ji používá pár lidí a vy jste jedním z nich, dozvíte se o výpadku dřív než monitoring.
• Služba, která běží jen v jednom regionu světa. Pokud je vaše služba dostupná jen v EU a vidíte ji z US jako DOWN, není to false positive, ale očekávaný stav.

Jak to máme v ePulz.io

ePulz.io má consensus voting v architektuře. gather_multiregion() a combine_consensus() v monitoring.py implementují výše popsaný pattern. Threshold (kolik regionů musí potvrdit DOWN) je nastavitelný přes parametr min_down.

V tabulce Check se pro každý check zaznamenává pole consensus s CSV (např. "primary:up,region_a:up,region_b:down"), takže při debugu máte přesný záznam, jak se rozhodnutí udělalo.

Závěr

Consensus voting není magické řešení. Nedá vám zero false positives a nezachrání vás při skutečném výpadku. Ale je to lepší kompromis než single-region (vysoké false positives při network anomáliích) nebo naivní multi-region (multiplikace false positives).

Podívejte se na ePulz.io. 7denní zkušební doba, 3 monitory, bez kreditky.

Související

• LAN monitoring přes pull-agent
• Moje IP adresa
• SSL check