Что делать, если сайт недоступен только для части пользователей? Классические сервисы uptime-мониторинга отвечают на этот вопрос через набор принадлежащих одному провайдеру точек проверки. Это удобно, пока провайдер и его точки доступны, а их география совпадает с реальной географией пользователей. Но при региональном сбое, проблемах с маршрутизацией или блокировке самого SaaS возникает неприятная петля: мы проверяем доступность сервиса через инфраструктуру, доступность которой сами не контролируем.

LibrePing — эксперимент с другой моделью. Это открытый мониторинг доступности, в котором результаты собирает не центральный сервер, а сеть независимых узлов на базе libp2p. Проект доступен на GitHub: https://github.com/mwgg/LibrePing. Живую демонстрацию можно открыть по адресу https://nl.lp.mw.gg.

Зачем ещё один мониторинг

У децентрализованной схемы есть практическая мотивация. Сбой нередко имеет региональный характер: из одной сети ресурс открывается, из другой — нет; DNS, CDN, транзитный оператор или конкретный дата-центр могут вести себя по-разному. Один SaaS-провайдер видит только свою картину мира и становится дополнительной точкой доверия. Узлы соединяются через libp2p и обмениваются данными в gossip-сети. Здесь важна не только доставка свежего результата. Узел может быть временно отключён, сменить адрес или подключиться к сети спустя несколько часов, поэтому LibrePing использует механизм anti-entropy: при повторном соединении участники догоняют пропущенные данные. Такой catch-up делает сеть устойчивее к кратковременным разрывам, чем модель, где единственный сервер должен постоянно принимать каждое событие.

Результаты распределяются между узлами, а не складываются в одну обязательную базу данных. Шардирование помогает не заставлять каждый probe хранить и обрабатывать абсолютно всё, что происходит в сети. При этом участник получает ту часть каталога и измерений, которая нужна ему для работы, а при восстановлении соединения может синхронизировать пропуски.

Одна цель — одна проверка на сеть

В распределённом мониторинге легко получить обратную проблему: десятки узлов начинают одновременно проверять одну и ту же цель, создавая лишний трафик и шум. Поэтому в проекте есть дедупликация: для конкретной цели выбирается одна проверка на сеть, а её результат затем становится общим наблюдением. Слой уведомлений отделён от публичного обмена измерениями. Адреса, куда отправляются тревоги, можно использовать в sealed-виде — например, для ntfy, Discord, Slack или произвольного webhook. Это позволяет не раздавать секреты всей mesh-сети и не превращать канал обмена результатами в хранилище токенов. Секрет остаётся у того узла, который должен отправить уведомление, а остальные участники видят только необходимую метаинформацию.

Как попробовать

Самый быстрый способ — открыть демонстрацию https://nl.lp.mw.gg и посмотреть, как выглядит мониторинг в работающей сети. Если хочется запустить собственный узел, в репозитории есть конфигурация для Docker Compose. Можно поднять hub в своей инфраструктуре и подключить к нему probe, либо начать с probe-only режима, не разворачивая отдельную панель.

Полезный сценарий для домашнего сервера или небольшой команды — запустить probe в нужной сети и сравнить его наблюдения с публичными. Так можно увидеть, что «сайт лежит» и «сайт недоступен из этой конкретной сети» — разные утверждения. Для инфраструктурной команды следующий шаг — добавить несколько probe в разных сегментах, а затем настроить собственный sealed-канал оповещений.

Ограничения и честные ожидания Что дальше

Главная ценность LibrePing сейчас — не обещание идеального единого SLA, а возможность проверять доступность из разных сетей без обязательного центрального владельца. Участник может запустить собственный hub, добавить probe, посмотреть на данные других узлов и при этом не отдавать секреты уведомлений внешнему SaaS.

Попробуйте демо: https://nl.lp.mw.gg. Исходный код и инструкции находятся в репозитории https://github.com/mwgg/LibrePing, а в wiki есть раздел Public hubs. Если вам близка идея мониторинга без центральной точки отказа, заведите probe, прогоните проект в своей сети и расскажите о результатах. Особенно полезны issues с наблюдениями о маршрутизации, восстановлении после разрыва и удобстве развёртывания.

Для сравнения подходов можно также прочитать англоязычный рассказ о проекте на DEV: https://dev.to/michael_volchenkov_4e3080/i-built-libreping-decentralized-uptime-monitoring-on-a-libp2p-mesh-odo и публикацию на Hashnode: https://libreping.hashnode.dev/libreping-open-source-uptime-monitoring-without-a-central-server. Проект пока не пытается выдавать эксперимент за готовую глобальную систему наблюдения. У LibrePing нет proof-of-location: подпись доказывает принадлежность результата ключу узла, но не доказывает, где физически находится машина и через какие независимые маршруты она вышла в интернет. Географические подписи и доверенные аттестации могут появиться позже, но сейчас их нет.

Mesh ещё растёт, поэтому покрытие, плотность узлов и качество данных зависят от участников. В отдельных случаях публичная сеть будет менее информативна, чем большой коммерческий сервис с десятками давно работающих точек. Наконец, LibrePing распространяется под AGPL. Лицензия подходит для открытой разработки и сетевых сервисов, но её условия стоит прочитать до включения проекта в закрытый продукт.

Это не означает, что у цели всегда будет ровно один физический probe. Смысл в том, чтобы координировать задания и не превращать мониторинг в неконтролируемый генератор запросов. При необходимости набор целей и правила распределения можно менять, а сеть продолжает собирать результаты независимо от единственного оператора.

Доверие к результату и уведомления

Децентрализация сама по себе не делает данные истинными. Любой узел может ошибиться, наблюдать нестабильный маршрут или прислать некорректный результат. Поэтому в LibrePing предусмотрены подписи результатов и каталога: получатель может проверить происхождение сообщения и связать его с конкретным ключом узла.

В LibrePing сеть проверок можно собрать из собственных и чужих узлов. Владелец сервиса получает не единственный вердикт «up/down», а наблюдения из разных сетевых окружений. Это полезно для диагностики маршрутизации и региональных проблем, а не только для отправки очередного уведомления о падении.

Архитектура: hub, probe и libp2p-сеть

Базовая схема состоит из hub и probe. Hub принимает и распространяет каталог целей и результаты измерений, а probe выполняет проверки из конкретного сетевого окружения. Один и тот же узел может совмещать обе роли либо работать только как probe — это позволяет подключать недорогие или ограниченные по ресурсам машины.