Monitoring multi-region: jak wyeliminować fałszywie pozytywne awarie

Fałszywe alarmy uczą zespół ignorowania alertów. Multi-region cross-check oznacza awarię dopiero wtedy, gdy potwierdzi ją kilka niezależnych sond.

Dlaczego monitoring single-region kłamie

Klasyczny monitoring ma jedną pozycję obserwacyjną (jeden serwer lub region chmurowy). Gdy ta sonda nie otrzyma odpowiedzi, zgłasza awarię. Przyczyną może być przy tym cokolwiek z poniższych:

Problem w sieci samej sondy (route flap, problem z peeringiem u jej dostawcy)
Krótkotrwały błąd DNS po stronie sondy
Geograficznie ograniczona awaria (padł edge CDN w jednym kraju)
Rate limiting lub blokada IP po stronie Twojej infrastruktury

Z perspektywy realnych użytkowników strona może być całkowicie w porządku - tylko niedostępna dla jednego konkretnego hosta monitorującego.

Konsekwencja: alert fatigue

Zespół, który otrzymuje 3 powiadomienia o "awarii" tygodniowo, z czego 2 to fałszywe alarmy (false-positive), stopniowo przestaje reagować. Gdy potem przyjdzie prawdziwa awaria, reakcja się opóźnia albo nikt jej nie zauważa. To zjawisko nazywa się alert fatigue (zmęczenie alertami) i jest dobrze udokumentowane w literaturze devops.

Celem jest jak najlepszy stosunek sygnału do szumu (signal-to-noise ratio). Lepiej dostać 1 powiadomienie miesięcznie, które jest zawsze realne, niż 10 powiadomień, z których 7 to szum.

Wzorzec multi-region: konsensus z N sond

Zasada:

Masz 3 węzły worker w 3 miastach (primary w Liptovský Hrádok, eu2 w Liptovský Mikuláš, eu1 w Bratysławie). Domyślny próg = 2 z 3, co daje rzeczywisty konsensus (nie jednomyślność). Architektura obsługuje dowolną liczbę węzłów, przy rozszerzeniu dołączają one do istniejącego mechanizmu konsensusu.
Przy każdym interwale wszystkie sondy równolegle testują endpoint.
Wyniki łączysz: awaria jest potwierdzona, jeśli zgłasza ją M z N sond (typowo M = 2 lub więcej).
Awaria jednej sondy nie wyzwala alarmu - jeśli jedna sonda zgłasza "down", ale pozostałe zgłaszają "up", system pozostaje w stanie UP.

To tak zwany consensus algorithm (algorytm konsensusu), podobny do Raft lub Paxos - decyzja zapada większością głosów.

Praktyczna konfiguracja

W panelu administracyjnym ePulz.io multi-region włącza się jednym przełącznikiem i konfiguruje przez:

Aktywne regiony - lista workerów, typowo 3-5
Próg konsensusu - ile regionów musi powiedzieć DOWN (domyślnie: 2)
Worker token - współdzielony tajny klucz (shared secret) między serwerem głównym a workerami do weryfikacji

Przy każdym sprawdzeniu serwer główny równolegle odpytuje wszystkich workerów przez HTTP API. Worker wykonuje lokalny test HTTP, TCP lub ping i zwraca wynik. Serwer główny ocenia konsensus i eskaluje alert dopiero wtedy, gdy zostanie przekroczony próg.

Trade-offs

Plusy:

Drastycznie mniej fałszywych alarmów
Wizualizacja geograficzna - widzisz, z których regionów strona nie działa
Wykrywanie regionalnych awarii (problem z PoP Cloudflare, błędny routing u ISP)

Minusy:

Nieco większe opóźnienie między realną awarią a alertem (czeka się na konsensus z wielu źródeł)
Wyższe wymagania infrastrukturalne i wyższy plan cenowy
Dostępność workerów - jeśli połowa workerów sama jest niedostępna, próg może być nieosiągalny (rozwiązaniem jest dynamiczny próg = M z aktualnie żywych sond)

Przykład obliczenia konsensusu

Konfiguracja 3 faktycznie wdrożonych węzłów worker: primary w Liptovský Hrádok (SK), eu2 w Liptovský Mikuláš (SK), eu1 w Bratysławie (SK), próg = 2.

Scenariusz	primary (Liptov)	eu1 (Bratysława)	eu2 (Liptov)	Alert?
Wszystko OK	UP	UP	UP	Nie
BGP flap między Liptovem a Twoim hostingiem	DOWN	UP	UP	Nie (1 z 3)
Awaria sprzętowa maszyny primary	DOWN	UP	DOWN	Tak (2 z 3)
Realna awaria Twojego serwera	DOWN	DOWN	DOWN	Tak

Jak wdrożyć własne workery

Worker to prosta usługa, która przyjmuje zadania kontrolne przez HTTPS, wykonuje test i zwraca wynik. ePulz.io obsługuje własne workery przez tunel WireGuard, więc mogą one działać na dowolnym VPS bez publicznego IP i komunikować się z serwerem głównym przez szyfrowany tunel.

Konfiguracja jednego workera zajmuje w praktyce około 10 minut (apt install wireguard, skopiowanie peer configu, systemctl enable). Otrzymujesz w ten sposób naprawdę niezależne pozycje obserwacyjne, które łączą różnorodność geograficzną (różne miasta) z redundancją sprzętową (różne maszyny w tym samym mieście).

Podsumowanie

Monitoring multi-region to nie tylko marketingowy frazes. To konkretny wzorzec inżynierski (kworum, czyli konsensus), który przenosi monitoring z poziomu "widzę to, co widzi jedna pozycja sieciowa" na poziom "widzę to, co widzi internet". Dla krytycznych aplikacji biznesowych jest to dziś standard.

Wyeliminuj fałszywie pozytywne alerty

Multi-region cross-check w planach bazowych (zarządzane centralnie). 7 dni za darmo.

Uruchom monitoring →