Голосування за консенсусом в uptime-моніторингу - чому це має сенс

Слабке місце моніторингу з одного регіону

Моніторинг з одного регіону означає, що перевірочний вузол працює в одній точці. Якщо на маршруті між цією точкою і Вашим сервером виникає мережева проблема (BGP flap, зміна маршрутизації, планові роботи у провайдера), монітор повідомляє DOWN, хоча сервер у порядку.

Це false positive. Ви отримуєте сповіщення, прокидаєтесь о 3 годині ночі, відкриваєте ноутбук - і виявляєте, що сайт працює.

Хибні спрацьовування шкідливі з двох причин:

1. Втома від сповіщень. Якщо Ви регулярно отримуєте повідомлення, які виявляються невірними, Ви поступово починаєте їх ігнорувати. Навіть справжні.
2. Втрата довіри до моніторингу. Команда перестає реагувати на алерти, бо "напевно, знову BGP".

Наївний multi-region розв'язує одну проблему і погіршує іншу

Поширений спосіб розв'язання - multi-region моніторинг. Перевірочний вузол працює з кількох локацій, і алерт спрацьовує, як тільки будь-яка з них повідомляє DOWN.

Це покращує виявлення справжніх збоїв: коли сервер дійсно недоступний, відпадає не один вузол, а одразу кілька. Добре.

Але проблема хибних позитивів стає гіршою. З одним вузлом у Вас була певна частка хибних алертів. З трьома вузлами математично вища ймовірність, що принаймні один з них помилково повідомить DOWN. Ви отримуєте більше хибних сповіщень, а не менше.

Голосування за консенсусом розв'язує обидва боки

Голосування за консенсусом працює інакше: при першому сигналі DOWN Ви не надсилаєте алерт. Спочатку Ви запитуєте інші регіони. Якщо більшість з них також повідомляють DOWN, це справжній збій. Якщо ні, це мережева аномалія в одному регіоні.

Псевдокод:

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'

Приклад сценарію:

primary  -> DOWN  (один вузол спіймав BGP flap)
region_a -> UP    (інші регіони бачать сервер нормально)
region_b -> UP

Result: UP. Без алерта. Запис в debug log.

І протилежний випадок, справжній збій:

primary  -> DOWN
region_a -> DOWN
region_b -> DOWN

Result: DOWN. Алерт іде через Telegram/email/webhook.

Компроміс: затримка

У голосування за консенсусом є ціна: при сигналі DOWN додається кілька секунд затримки на опитування інших регіонів. Для більшості сценаріїв (uptime monitoring з хвилинним інтервалом) це непомітно. Для надто суворих SLA з часом виявлення менше 30 секунд це може бути компромісом.

Коли multi-region не має сенсу

• Внутрішні API на 192.168.x.x. Ніхто ззовні Вашої мережі не може їх досягти, тому multi-region з інтернету безглуздий. Для LAN використовуйте патерн pull-agent: агент працює у Вашій мережі і надсилає результати через HTTPS.
• Внутрішній застосунок для одного клієнта. Якщо ним користується кілька осіб, і Ви один з них, Ви дізнаєтесь про збій раніше за моніторинг.
• Сервіс, що працює тільки в одному регіоні світу. Якщо Ваш сервіс лише для ЄС, і Ви бачите його як DOWN зі США, це не false positive - це очікувано.

Як це зроблено в ePulz.io

В архітектурі ePulz.io голосування за консенсусом реалізоване вбудовано. Функції gather_multiregion() і combine_consensus() в monitoring.py реалізують описаний вище патерн. Поріг (скільки регіонів мають підтвердити DOWN) налаштовується через параметр min_down.

В таблиці Check кожен рядок зберігає поле consensus у форматі CSV (наприклад, "primary:up,region_a:up,region_b:down"), тож для зневадження у Вас є точний запис про те, як було ухвалене рішення.

Для self-hosting воркера в іншому регіоні адмінка містить генератор WireGuard-бандлу: він створює tar.gz з конфігурацією для нового воркер-вузла і додає його до worker_urls.

Висновок

Голосування за консенсусом не магічне рішення. Воно не дасть Вам нуль false positive і не врятує під час справжнього збою. Але це кращий компроміс, ніж single-region (багато false positive при мережевих аномаліях) або наївний multi-region (множення хибних спрацьовувань).

Спробуйте ePulz.io. 7-денна пробна версія, 3 монітори, без картки.

Схоже

• LAN моніторинг через pull-agent
• My IP Address
• SSL check