Я выпустил MirvMon v0.8.0.
Последняя запись на сайте была про v0.7.0 и появление Observations. С тех пор MirvMon успел пройти ещё семь промежуточных релизов, а в 0.8.0 получил уже следующий крупный слой: измерение надёжности, публичную status page и оценку того, насколько полезными оказались predictive-наблюдения.
Главное в v0.8.0
В MirvMon появился отдельный отчёт о надёжности за 7 или 30 дней. Для серверов и сайтов он показывает доступность, полноту наблюдений, число и длительность инцидентов и среднее время восстановления.
Здесь есть важная оговорка: MirvMon не пытается рисовать красивую цифру любой ценой. Если за выбранный период получено меньше 95% ожидаемых измерений, доступность не публикуется как достоверное значение. То есть отсутствие данных не превращается в ложные «99.99%».
Второе крупное изменение — публичная статусная страница по адресу /status. Она полностью opt-in: администратор сам выбирает, какие серверы и сайты показывать наружу и какие публичные имена им дать. По умолчанию список пуст. Внутренние адреса, метрики и подробности инцидентов туда не попадают.
Третье — у predictive observations появилась оценка исхода эпизода. После наблюдения оператор может отметить, что это был полезный сигнал, обычное поведение, проблема была предотвращена действием или результат остался неясным. Эти оценки нужны для последующего анализа качества и не обучают детектор и не меняют его решения.
Что изменилось после v0.7.0
Сам слой Observations за это время заметно повзрослел.
В v0.7.1 MirvMon научился объединять прогнозы заполнения диска, если один и тот же filesystem виден под несколькими mount alias. Например, bind-mount’ы больше не должны создавать несколько одинаковых предупреждений.
В v0.7.2 исправлена идентичность anomaly episode: одно непрерывное отклонение CPU/RAM остаётся одним наблюдением, даже если нагрузка проходит через несколько внутренних диапазонов. Появилось действие «Проверено» — можно погасить текущий эпизод, не объявляя такое поведение нормой навсегда.
В v0.7.3 детектор CPU/RAM был заметно переработан. Вместо сравнения с одной общей медианой используется контекстная история до восьми недель: сначала тот же день недели и локальное время, затем более широкие weekday/weekend и time-of-day профили. Если данных недостаточно, MirvMon предпочитает промолчать, а не выдать сомнительную аномалию. Для recovery добавлен устойчивый нормальный интервал, чтобы наблюдения не дёргались туда-сюда на границе.
Maintenance теперь ведёт себя как режим тишины, а не как выключение мониторинга
В v0.7.5 уточнена и исправлена логика maintenance windows.
Сбор данных, website checks, история и фиксация incidents во время обслуживания продолжаются. Подавляется именно доставка уведомлений.
Если проблема началась во время maintenance и всё ещё существует после его завершения, MirvMon отправляет одно явное post-maintenance уведомление. Если же проблема успела начаться и закончиться внутри окна — после обслуживания не прилетает бессмысленная пара trigger/recovery.
Мониторинг сайтов стал устойчивее
В v0.7.7 закрыта неприятная группа проблем вокруг website monitoring.
Автоматическое закрытие website incidents после последовательных успешных проверок снова работает корректно. Счётчики переходов ограничены, поэтому длительно работающий worker больше не должен упасть из-за переполнения PostgreSQL smallint.
Также появились диагностика очереди website checks и ручной requeue исчерпанных заданий, исправлены critical/warning-фильтры и переходы со сводных карточек.
Немного внешнего вида и полировки
В v0.7.4 у MirvMon появился единый визуальный знак и wordmark в navbar, login/setup и favicon.
v0.7.6 был небольшим hotfix-релизом: убран буквальный \n, который мог протечь в общую Twig-разметку страниц, и добавлен тест, чтобы подобное не вернулось.
Зачем понадобился отчёт о надёжности
До 0.8.0 MirvMon уже хорошо отвечал на вопросы «что сейчас сломано?» и «что ведёт себя необычно?». Но для реальной эксплуатации часто нужен ещё один слой:
- насколько стабильно этот сервер или сайт работает в целом;
- сколько реально было инцидентов;
- как долго они длились;
- сколько в среднем занимало восстановление;
- достаточно ли вообще данных, чтобы этим цифрам доверять.
Именно для этого появился Reliability Report. Он не заменяет графики и incidents, а собирает их в эксплуатационную картину за период.
Обновление
Для v0.8.0 используется образ:
ghcr.io/mirivlad/mirvmon:0.8.0
Перед обновлением, как обычно, стоит сделать резервную копию базы. Миграции 029 и 030 применяются автоматически.
Новых Compose-сервисов, обязательных переменных окружения и изменений протокола агента в 0.8.0 нет — переустанавливать агентов не требуется.
Ссылки
Страница проекта MirvMon
Исходный код
MirvMon v0.8.0 на GitHub
Установка и обновление