Мультирегіональний моніторинг: як усунути хибнопозитивні збої

Хибні тривоги привчають команду ігнорувати сповіщення. Мультирегіональна крос-перевірка позначає збій лише тоді, коли його підтверджують кілька незалежних зондів.

Чому моніторинг з одного регіону бреше

У класичного моніторингу одна точка спостереження (один сервер або хмарний регіон). Коли цей зонд не отримує відповіді, він повідомляє про збій. При цьому причиною може бути будь-що з наступного:

Проблема в мережі самого зонда (route flap, проблема пірингу в його провайдера)
Короткочасний збій DNS на боці зонда
Географічно обмежений збій (упав CDN-edge в одній країні)
Rate limiting або блокування IP на боці вашої інфраструктури

З точки зору реальних користувачів сайт може бути цілком справним - просто недоступним для одного конкретного хоста моніторингу.

Наслідок: втома від сповіщень

Команда, яка отримує 3 сповіщення про "збій" на тиждень, з яких 2 - хибні тривоги (хибнопозитивні), поступово перестає реагувати. Коли потім приходить справжній збій, реакція запізнюється або його ніхто не помічає. Це явище називається alert fatigue (втома від сповіщень) і добре задокументоване в devops-літературі.

Мета - якнайкраще співвідношення сигнал/шум (signal-to-noise ratio). Краще отримувати 1 сповіщення на місяць, яке завжди реальне, ніж 10 сповіщень, з яких 7 - шум.

Мультирегіональний патерн: консенсус із N зондів

Принцип:

У вас 3 worker-ноди в 3 містах (primary у Ліптовському Градку, eu2 в Ліптовському Мікулаші, eu1 у Братиславі). Поріг за замовчуванням = 2 з 3, що дає справжній консенсус (а не одностайність). Архітектура підтримує будь-яку кількість нод; під час розширення вони додаються до наявного механізму консенсусу.
На кожному інтервалі всі зонди паралельно тестують endpoint.
Результат об'єднується: збій підтверджено, якщо про нього повідомляють M із N зондів (зазвичай M = 2 або більше).
Відмова одного зонда не запускає тривогу - якщо один зонд повідомляє "down", а інші "up", система залишається у стані UP.

Це так званий consensus algorithm (алгоритм консенсусу), подібний до Raft чи Paxos - рішення ухвалюється більшістю голосів.

Практичне налаштування

В адмін-панелі ePulz.io мультирегіон вмикається одним перемикачем і налаштовується через:

Активні регіони - список воркерів, зазвичай 3-5
Поріг консенсусу - скільки регіонів мають сказати DOWN (за замовчуванням: 2)
Worker token - спільний секрет (shared secret) між головним сервером і воркерами для перевірки

Під час кожної перевірки головний сервер паралельно опитує всіх воркерів через HTTP API. Воркер виконує локальний HTTP-, TCP- або ping-тест і повертає результат. Головний сервер оцінює консенсус і ескалює сповіщення лише тоді, коли перевищено поріг.

Компроміси

Плюси:

Різко менше хибних тривог
Географічна візуалізація - ви бачите, з яких регіонів сайт не працює
Виявлення регіональних збоїв (проблема з PoP Cloudflare, хибна маршрутизація в ISP)

Мінуси:

Дещо більша затримка між реальним збоєм і сповіщенням (очікується консенсус із кількох джерел)
Вищі вимоги до інфраструктури та дорожчий тарифний план
Доступність воркерів - якщо половина воркерів сама недоступна, поріг може бути недосяжним (рішення - динамічний поріг = M із наразі живих зондів)

Приклад розрахунку консенсусу

Конфігурація з 3 реально розгорнутих worker-нод: primary у Ліптовському Градку (SK), eu2 в Ліптовському Мікулаші (SK), eu1 у Братиславі (SK), поріг = 2.

Сценарій	primary (Ліптов)	eu1 (Братислава)	eu2 (Ліптов)	Alert?
Усе OK	UP	UP	UP	Ні
BGP flap між Ліптовом і вашим хостингом	DOWN	UP	UP	Ні (1 з 3)
Апаратна відмова машини primary	DOWN	UP	DOWN	Так (2 з 3)
Реальний збій вашого сервера	DOWN	DOWN	DOWN	Так

Як розгорнути власні воркери

Воркер - це простий сервіс, який приймає задачі перевірки через HTTPS, виконує тест і повертає результат. ePulz.io підтримує власні воркери через WireGuard-тунель, тож вони можуть працювати на будь-якому VPS без публічного IP і спілкуватися з головним сервером через зашифрований тунель.

Налаштування одного воркера на практиці займає приблизно 10 хвилин (apt install wireguard, копіювання peer-конфігу, systemctl enable). Так ви отримуєте справді незалежні точки спостереження, які поєднують географічну різноманітність (різні міста) з апаратною надлишковістю (різні машини в одному місті).

Висновок

Мультирегіональний моніторинг - це не просто маркетинговий штамп. Це конкретний інженерний патерн (кворум, тобто консенсус), який переводить моніторинг з рівня "я бачу те, що бачить одна мережева позиція" на рівень "я бачу те, що бачить інтернет". Для критичних бізнес-застосунків сьогодні це стандарт.

Усуньте хибнопозитивні сповіщення

Мультирегіональна крос-перевірка в базових тарифах (централізовано керована). 7 днів безкоштовно.

Запустити моніторинг →