Я выпустил MirvMon v0.7.0.
На этот раз главное изменение — не ещё один тип графика и не новый порог алерта. В MirvMon появился отдельный слой Observations: система теперь может заметить, что сервер начал вести себя необычно, ещё до того, как случился обычный incident.
Зачем это вообще нужно
Обычный мониторинг хорошо отвечает на вопрос: «порог уже превышен?»
Например, CPU выше 90%, свободного места осталось меньше 10%, сервис не отвечает — открываем incident и отправляем уведомление.
Но в реальной работе часто важнее другое. Допустим, сервер DB1 месяцами живёт с загрузкой CPU около 2–3%, а потом внезапно начинает по полчаса держаться на 20%. Формально всё прекрасно: никакой порог не пересечён. Но для конкретно этого сервера поведение явно изменилось.
Или диск не заполнен прямо сейчас, но свободное место убывает настолько стабильно, что через день-два он, скорее всего, упрётся в warning или вообще заполнится.
Именно такие вещи теперь и ловит MirvMon.
Observations — это не Incidents
Я намеренно не стал превращать каждое отклонение в аварию. В 0.7.0 наблюдения живут отдельно от Incidents и Events.
У них есть свои активные записи, история и список шаблонов, которые оператор уже признал нормальным поведением.
То есть MirvMon может сказать примерно следующее:
- «Для этого сервера загрузка CPU долгое время была существенно выше его обычного уровня»;
- «Такой скачок повторяется регулярно»;
- «При текущем темпе заполнения диск может скоро дойти до warning/full».
Это ещё не авария. Это повод посмотреть, что изменилось.
CPU и RAM: сравнение не с чужим порогом, а с самим сервером
Для CPU и RAM анализатор ищет устойчивые и повторяющиеся сдвиги относительно собственной исторической базы конкретного сервера.
Это важный момент: 20% CPU сами по себе не «много» и не «мало». Для сервера, который обычно работает на 60%, это вообще ничего интересного. А для машины, которая месяцами сидела на 2–3%, устойчивые 20% уже могут быть полезным сигналом.
Поэтому Observations не заменяют обычные thresholds. Они отвечают на другой вопрос: «сервер всё ещё ведёт себя так, как обычно?»
Диск: предупреждение до того, как место закончилось
Для дисков в 0.7.0 появился прогноз роста заполнения.
MirvMon анализирует исторический тренд, учитывает очистки диска и не пытается продолжать старую линию через очевидный cleanup. Если данных достаточно и качество прогноза приемлемое, система оценивает, когда диск может дойти до warning-порога и когда — заполниться.
Так можно получить предупреждение не «места уже осталось 9%», а условное «при текущем тренде завтра стоит заняться этим диском».
Оператор может объяснить системе, что происходит
Без обратной связи такой анализатор очень быстро превратился бы в ещё один генератор шума. Поэтому для наблюдений есть действия оператора.
- Обработано — удобно для прогнозов вроде заполнения диска. Наблюдение снимается и не беспокоит снова, пока условие действительно не очистится. Если потом возникнет новый независимый эпизод — MirvMon сможет предупредить заново.
- Это нормально — если обнаруженная аномалия на самом деле является обычным режимом работы конкретного сервера, её можно принять как нормальный паттерн.
- Вернуть в анализ — ранее принятый паттерн можно снова сделать активным для анализа.
Все эти действия пишутся в append-only audit log.
Уведомления без фальшивых аварий
Observations используют уже существующую систему получателей MirvMon: те же Telegram/SMTP-настройки и подписки на конкретные серверы.
Но при этом наблюдение не создаёт фальшивую строку incident только ради того, чтобы пройти через систему уведомлений. Для него используется отдельная логика, а повторные уведомления внутри одного и того же эпизода дедуплицируются.
Никаких новых агентов
Сам анализ выполняет новый observation-worker на серверной стороне. Он работает с уже накопленной историей TimescaleDB.
Протокол нативных агентов не менялся, дополнительный сервис в Compose тоже не появился: worker запускается внутри существующего application container под Supervisor.
Поэтому обновление с 0.6.9 на 0.7.0 не требует переустановки агентов, ротации agent tokens или изменения их конфигурации.
Обновление
Текущая стабильная версия — v0.7.0.
ghcr.io/mirivlad/mirvmon:0.7.0Для существующей Docker/Portainer-установки достаточно обычного re-pull/redeploy stack. Миграция 024_observations.sql применяется штатным механизмом миграций.
GitHub: github.com/mirivlad/mirvmon
Релиз v0.7.0: github.com/mirivlad/mirvmon/releases/tag/v0.7.0
Установка: INSTALL.md
Итого
Для меня это довольно заметный шаг в развитии MirvMon. До 0.7.0 система в основном фиксировала текущее состояние: нормально, warning, incident, восстановление.
Теперь появляется ещё один слой: поведение во времени.
То есть мониторинг начинает замечать не только «сломалось», но и «что-то здесь изменилось» или «если всё продолжится так же, скоро будет проблема».
И при этом последнее слово остаётся за оператором: он может сказать системе, что конкретная аномалия нормальна, или отметить прогноз как обработанный.
Мне кажется, именно таким и должен быть проактивный мониторинг: не пытаться заменить человека, а вовремя подсказать ему, куда стоит посмотреть.