Я выпустил MirvMon v0.9.3 и на этом считаю ветку 0.9 законченной.
Главное изменение всей серии 0.9.x — распределённые проверки сайтов через уже установленные серверные агенты. Раньше на HTTP(S)-сайт смотрел только сам MirvMon. Теперь к этой центральной точке можно добавить нужные агенты на наблюдаемых серверах и задать failure quorum.
Никаких отдельных probe-сервисов и входящих портов для этого не появилось: используется тот же native agent и та же outbound-only модель, что и для серверных метрик.
Зачем понадобились распределённые проверки
Центральная проверка отвечает на простой вопрос: «видит ли сайт сервер, на котором работает MirvMon?»
Но это не всегда то же самое, что «доступен ли сайт вообще?». Может сломаться маршрут у самого MirvMon, конкретный провайдер, VPN, DNS-путь или связность между двумя площадками. При одной точке наблюдения всё это выглядит одинаково: HTTP-запрос не прошёл.
В 0.9 я не стал строить отдельную сеть probe-нод. Они уже есть — это MirvMon agents на серверах. Если конкретный агент поддерживает capability website_probe_v1, его можно включить как дополнительную точку проверки сайтов.
Как это устроено
Central MirvMon участвует в проверке всегда. Выключить его или заменить набором агентов нельзя.
В настройках сайта выбираются только дополнительные серверные агенты. Агент получает назначенные HTTP(S)-jobs через свой обычный outbound config, выполняет transport-проверку и возвращает результат через тот же durable metrics envelope. Если связь с MirvMon временно пропала, результат проходит через существующую локальную очередь агента.
То есть с точки зрения сети модель не изменилась:
- агент сам инициирует соединение с MirvMon;
- на наблюдаемом сервере не нужен входящий порт;
- не нужен белый IP;
- не появляется ещё один отдельный демон или контейнер.
Quorum: когда считать сайт недоступным
Для каждого сайта задаётся failure quorum — сколько точек должны одновременно видеть transport failure, чтобы MirvMon признал транспортную проверку неуспешной.
Например, есть Central и два агента, а quorum равен 2.
Если сайт не видит только один агент — этого недостаточно. Если не видят любые две точки из трёх — quorum достигнут. Это именно число отказавших точек, а не заранее заданная группа.
Есть ещё важное правило: отсутствующий или устаревший результат агента не считается отказом. Такая точка имеет состояние «нет свежих данных». Иначе потеря связи самого агента с MirvMon могла бы искусственно превращаться в outage сайта.
На карточках сайтов это теперь видно сразу: зелёные, красные и серые точки показывают состояние каждой точки, а рядом отдельно отображается, сколько failures уже набрано относительно quorum.
Что именно проверяют агенты
Удалённая проверка сознательно осталась узкой: только transport HTTP(S).
Агенту не передаются auth secrets и custom headers. Он не занимается TLS expiry, сроком регистрации домена, content/status assertions и другими семантическими проверками сайта — всё это остаётся за Central MirvMon.
Полученный HTTP-ответ, в том числе 4xx или 5xx, для remote point означает, что transport до HTTP-сервера состоялся. А уже вопрос «тот ли это HTTP status, тот ли текст на странице, подходит ли сертификат» решает центральный checker.
Endpoint с authentication, пользовательскими headers или разрешённым self-signed TLS агенту вообще не выдаётся. Для такого endpoint MirvMon автоматически использует эффективный quorum 1: Central остаётся единственной transport-точкой, и её реальный отказ не может быть замаскирован отсутствующими remote results.
Что появилось в интерфейсе
В 0.9.1 распределённые проверки стали нормальной частью интерфейса, а не только настройкой в форме сайта.
В списке серверов и в обзоре агентов появился быстрый переключатель «Проверки сайтов». Старые агенты без website_probe_v1 сразу показываются как неподдерживающие эту функцию.
Карточка сайта показывает состояние всех реально участвующих точек и отдельный quorum-индикатор. Central визуально отличим от агентов, но выбирать его в форме больше не нужно — он обязателен всегда.
В v0.9.3 на вкладке События появилась ещё и компактная история точек за последние семь дней: переходы «доступно / недоступно» и последнее состояние каждой точки. После инцидента теперь можно посмотреть не только факт проблемы, но и кто именно перестал видеть endpoint.
Заодно в 0.9.1 была приведена в порядок верхняя навигация: серверы собраны в dropdown, настройки перенесены в меню пользователя, а активные разделы получили более понятную визуальную индикацию.
Надёжность теперь считает ту же картину
После первого варианта distributed probes оставался неприятный смысловой разрыв: live incident pipeline уже учитывал quorum, а Reliability Report всё ещё считал сайт только по центральным samples.
В v0.9.3 это закрыто.
Для каждой центральной автоматической проверки основного endpoint отчёт берёт свежие observations выбранных remote points и применяет тот же failure quorum. Assertions при этом по-прежнему подтверждает только Central MirvMon.
То есть ситуация «Central видит сайт, но достаточное число удалённых точек одновременно не видит» теперь одинаково отражается и в текущем состоянии, и в отчёте надёжности.
Распределённые сайты прямо помечаются в отчёте числом точек и quorum.
Ещё несколько исправлений в 0.9.2
В 0.9.2 Central был закреплён как обязательная точка уже не только в UI, но и как инвариант БД. Старое состояние с отключённым Central автоматически исправляется миграцией 032.
Тогда же поправил ещё две вещи, которые обнаружились уже при реальном использовании.
Во-первых, availability сайта теперь не исчезает только потому, что выбранный семидневный период ещё не успел полностью накопиться. Если проверки уже есть, MirvMon показывает рассчитанную доступность, а при coverage ниже 95% честно ставит пометку «Неполный период». Для серверов строгий порог полноты остаётся.
Во-вторых, вся локальная CSS/JS-статика получила cache-busting по версии релиза. После обновления больше не должно требоваться ручное Ctrl+R, чтобы браузер наконец увидел новые стили.
И ещё маленькая UI-правка: карточка «Всего серверов» на главном обзоре теперь кликабельна и снимает status-фильтр, возвращая полный список.
Что в итоге получилось
Ветка 0.9 не превращает MirvMon в универсальный synthetic-monitoring комбайн. У неё довольно конкретная задача: не делать вывод о доступности сайта только по одной сетевой точке, когда в инфраструктуре уже есть агенты, способные дать дополнительные наблюдения.
При этом остаются прежние принципы MirvMon: минимум новых сущностей, исходящие соединения агентов, отсутствие лишних открытых портов и достаточно прозрачная логика принятия решения.
Обновление
Текущий стабильный релиз:
ghcr.io/mirivlad/mirvmon:0.9.3
Если обновление идёт с версии до 0.9.0, штатно применятся необходимые миграции. В самой v0.9.3 новых миграций и изменений agent protocol нет.
Для использования удалённой точки агент должен поддерживать website_probe_v1. Остальные агенты продолжают работать как обычно, просто не могут быть назначены для website probes.
Ссылки
Страница проекта MirvMon
Исходный код
MirvMon v0.9.3 на GitHub
Установка и обновление