Голосование по консенсусу в 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