Consensus voting w monitoringu uptime - dlaczego ma sens

Słaba strona monitoringu single-region

Single-region monitoring oznacza, że twój checker działa w jednej lokalizacji. Jeśli między tą lokalizacją a twoim serwerem wystąpi problem sieciowy (BGP flap, routing change, prace serwisowe ISP), monitor zgłosi DOWN, mimo że serwer jest sprawny.

To false positive. Dostajesz alert, budzisz się o trzeciej w nocy, otwierasz laptopa i okazuje się, że strona działa.

False positives szkodzą z dwóch powodów:

1. Alert fatigue. Jeśli otrzymujesz powiadomienia, które okazują się nieprawdziwe, stopniowo zaczynasz je ignorować. Także te prawdziwe.
2. Utrata zaufania do monitoringu. Zespół przestaje reagować na alerty, bo "to znowu pewnie tylko BGP".

Naiwny multi-region rozwiązuje jeden problem, pogarsza drugi

Powszechnym sposobem rozwiązania tego problemu jest multi-region monitoring. Checker działa z kilku lokalizacji, a alert wysyłany jest za każdym razem, gdy którakolwiek z nich zgłosi DOWN.

Tym samym poprawia się detekcja rzeczywistych awarii - gdy serwer jest naprawdę niedostępny, nie zgaśnie tylko jeden checker, ale kilka. To w porządku.

Jednak problem z false positives się pogłębi. Przy jednym checkerze miałeś pewien wskaźnik fałszywych alertów. Przy trzech checkerach jest matematycznie bardziej prawdopodobne, że co najmniej jeden z nich fałszywie zgłosi DOWN. Dostajesz więcej fałszywych alertów, a nie mniej.

Consensus voting rozwiązuje obie strony problemu

Consensus voting działa inaczej: przy pierwszym sygnale DOWN alert nie jest wysyłany. Najpierw pytasz pozostałe regiony. Jeśli większość z nich też zgłasza DOWN, to rzeczywista awaria. Jeśli nie, to anomalia sieciowa w jednym regionie.

Pseudokod:

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'

Przykład sytuacji:

primary  → DOWN  (jeden checker miał BGP flap)
region_a → UP    (pozostałe regiony widzą serwer normalnie)
region_b → UP

Wynik: UP. Brak alertu. Wpis w debug logu.

I odwrotnie przy rzeczywistej awarii:

primary  → DOWN
region_a → DOWN
region_b → DOWN

Wynik: DOWN. Alert idzie przez Telegram/email/webhook.

Tradeoff: latencja

Consensus voting ma swoją cenę - przy sygnale DOWN dodaje kilka sekund latencji, zanim zdąży zapytać pozostałe regiony. Dla większości use-case'ów (uptime monitoring z minutowym interwałem) jest to pomijalne. Dla niezwykle rygorystycznych SLA z detection time poniżej 30 sekund może to być kompromis.

Kiedy multi-region nie ma sensu

• Wewnętrzne API na 192.168.x.x. Nikt poza twoją siecią się tam nie dostanie, więc multi-region z internetu nie ma sensu. Dla LAN użyj pull-agent pattern - agent działa w twojej sieci, wyniki wysyła przez HTTPS.
• Single-customer aplikacja wewnętrzna. Jeśli używa jej kilka osób, a ty jesteś jedną z nich, dowiesz się o awarii wcześniej niż monitoring.
• Service działający tylko w jednym regionie świata. Jeśli twoja usługa jest dostępna tylko w UE i widzisz ją z US jako DOWN, to nie jest false positive - to oczekiwany stan.

Jak to mamy w ePulz.io

ePulz.io ma consensus voting w architekturze. gather_multiregion() i combine_consensus() w monitoring.py implementują opisany powyżej wzorzec. Threshold (ile regionów musi potwierdzić DOWN) jest konfigurowalny przez parametr min_down.

W tabeli Check dla każdego checku zapisywane jest pole consensus z CSV (np. "primary:up,region_a:up,region_b:down"), więc przy debugu masz dokładny zapis, jak została podjęta decyzja.

Do samohostowania workera w kolejnym regionie mamy w panelu admina generator WireGuard bundle - tworzy tar.gz z konfiguracją dla nowego worker node i dodaje go do worker_urls.

Podsumowanie

Consensus voting nie jest magicznym rozwiązaniem. Nie da ci zero false positives i nie uratuje cię przy rzeczywistej awarii. Ale to lepszy kompromis niż single-region (wysokie false positives przy anomaliach sieciowych) lub naiwny multi-region (mnożenie false positives).

Zerknij na ePulz.io. 7-dniowy okres próbny, 3 monitory, bez karty.

Powiązane

• LAN monitoring przez pull-agent
• Moje IP
• SSL check