MirvMon

GitHub →Документация →Скачать →Сообщить об ошибке →
← Все публичные проекты

MirvMon — self-hosted-система мониторинга серверов и сайтов для домашней и небольшой рабочей инфраструктуры.

Она рассчитана на ситуацию, когда одному администратору или небольшой команде нужен понятный обзор собственной инфраструктуры без развёртывания тяжёлого enterprise-стека. Нативные агенты сами отправляют данные на сервер по HTTPS, поэтому наблюдаемым машинам не нужны входящие порты или белые IP-адреса.

MirvMon хранит историю метрик и доступности, следит за сайтами и сервисами, умеет проверять сайты сразу из нескольких точек через уже установленные серверные агенты, ведёт инциденты и проактивные наблюдения, считает показатели надёжности, умеет публиковать безопасную status page, отправляет уведомления, позволяет централизованно обновлять агентов и восстанавливать систему из резервной копии через единый веб-интерфейс.

Главный экран MirvMon

Основные возможности

  • мониторинг Linux и Windows нативным Go-агентом;
  • исходящие HTTPS-соединения от агентов без необходимости открывать входящие порты;
  • метрики CPU, RAM, дисков, I/O, сети, температуры, uptime, процессов и системных сервисов;
  • история и графики на PostgreSQL + TimescaleDB с периодами от часа до года;
  • группы серверов, оперативные сводки и live-обновление интерфейса;
  • пороговые warning/critical-состояния, recovery и единая лента Incidents / Events;
  • Telegram и SMTP через outbox с retry/backoff и индивидуальными получателями;
  • графики в уведомлениях для серверных метрик и измеряемых проверок сайтов;
  • maintenance windows без остановки сбора данных и с post-maintenance уведомлением для сохранившихся проблем;
  • проактивные Observations для необычных CPU/RAM-паттернов и прогноза заполнения дисков;
  • оценка исходов predictive observations для последующего анализа качества без автоматического переобучения детектора;
  • отчёт о надёжности серверов и сайтов за 7/30 дней: availability, coverage, инциденты и среднее время восстановления;
  • opt-in публичная status page с явно выбранными объектами и публичными именами;
  • мониторинг HTTP/HTTPS-сайтов: несколько endpoint, допустимые статусы, redirects, TLS, проверка текста, auth/headers, время ответа и сроки доменов;
  • распределённые transport HTTP(S)-проверки сайтов через выбранные серверные агенты с Central MirvMon как обязательной точкой и настраиваемым failure quorum;
  • диагностика очереди website checks и ручной requeue исчерпанных заданий;
  • установка и самообновление агентов из веб-интерфейса, массовое обновление и обзор версий парка;
  • совместимые сборки и сценарии обновления для legacy Windows и SysV-систем;
  • самодиагностика MirvMon, PostgreSQL/TimescaleDB, worker’ов, очереди уведомлений и хоста;
  • проверка внешней сетевой связности по контрольным узлам и кворуму;
  • роли user, operator и admin;
  • append-only журнал административных действий;
  • зашифрованный Backup & Disaster Recovery с переносом действующих credentials агентов;
  • русский и английский интерфейс;
  • Docker/Portainer-развёртывание, multi-arch образы amd64/arm64 и работа за reverse proxy.

Проактивные наблюдения

Обычный пороговый мониторинг отвечает на вопрос: «что уже вышло за допустимые пределы?» Отдельный слой Observations пытается раньше заметить другое: «что ведёт себя необычно для конкретного сервера, хотя warning ещё не достигнут?»

Для CPU и RAM MirvMon строит контекстный профиль по истории до восьми недель. Нагрузка сравнивается прежде всего с тем же днём недели и локальным временем, затем с более широкими временными контекстами. Поэтому обычные дневные 25–70% CPU не должны считаться аномалией только потому, что ночью этот же сервер работает на 5–10%.

Одно непрерывное отклонение считается одним эпизодом даже при изменении уровня нагрузки. Кратковременное ослабление признака аномалии не считается восстановлением: для закрытия observation требуется устойчивый возврат к нормальному диапазону. Если нагрузка уже дошла до обычного warning threshold, сигнал передаётся incident pipeline, а observation не создаёт конкурирующую аварию.

Для дисков MirvMon анализирует тренд заполнения и оценивает время до warning-порога и полного заполнения. После заметной очистки старый тренд не продолжается механически — начинается новый участок анализа. Алиасы одного filesystem объединяются, чтобы один и тот же диск не порождал несколько одинаковых прогнозов.

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

Начиная с v0.8.0 исход каждого predictive-эпизода можно отдельно оценить как полезный сигнал, обычное поведение, предотвращённую действием проблему или неясный результат. Эта оценка нужна для анализа качества и не меняет работу детектора.

Подробнее об истории появления Observations →

Распределённые проверки сайтов

Начиная с ветки 0.9 один сайт может проверяться не только самим MirvMon, но и выбранными серверными агентами. Central MirvMon участвует всегда, а агенты становятся дополнительными точками наблюдения без новых входящих портов: задания и результаты проходят через существующий outbound-only протокол агента.

Для сайта задаётся failure quorum — сколько точек должны одновременно видеть transport failure, чтобы проверка считалась неуспешной. Отсутствующий или устаревший результат агента считается неизвестным состоянием, а не отказом.

Удалённые агенты выполняют только transport HTTP(S)-проверку. TLS expiry, срок регистрации домена, content/status assertions и другие семантические проверки остаются централизованными. Auth secrets и custom headers агентам не передаются; endpoint, который нельзя безопасно отдать агенту, автоматически проверяется с effective quorum 1 только через Central.

На карточках сайтов видны состояния точек и текущий quorum, а во вкладке событий хранится компактная семидневная история переходов по каждой точке.

Надёжность и публичный статус

Раздел Аналитика → Отчёт о надёжности собирает эксплуатационную картину за 7 или 30 дней: доступность, полноту наблюдений, число и длительность инцидентов и среднее время восстановления для серверов и сайтов.

Для распределённо проверяемых сайтов availability использует ту же transport-семантику, что и live monitoring: свежие результаты Central и выбранных agents сравниваются с failure quorum, а assertions остаются Central-only. В отчёте видно количество точек и quorum.

Если сайт наблюдается меньше выбранного периода, MirvMon всё равно показывает availability по реально полученным автоматическим проверкам и помечает результат как «Неполный период» при coverage ниже 95%. Для серверов строгий порог полноты 95% сохраняется.

Публичная страница /status включается только явно. Администратор выбирает конкретные серверы и сайты и задаёт им публичные имена. По умолчанию список пуст; внутренние адреса, метрики и подробности инцидентов наружу не публикуются.

Maintenance windows

Режим обслуживания в MirvMon означает «не будить оператора», а не «перестать наблюдать». Во время maintenance агенты и website checks продолжают работать, метрики и история сохраняются, а alerts/incidents фиксируются как обычно.

Если проблема возникла во время обслуживания и остаётся активной после окончания окна, MirvMon отправляет одно явно помеченное post-maintenance уведомление. Если проблема успела начаться и закончиться внутри maintenance, догоняющей пары trigger/recovery после окна не будет.

Состояние проекта

Статус: активная разработка; актуальный стабильный релиз — Последняя стабильная версия MirvMon на GitHub.
Платформы: сервер — Docker/Portainer; агенты — Linux и Windows.
Технологии: PHP 8.5, Slim 4, Twig 3, FrankenPHP, PostgreSQL 17, TimescaleDB, Go, Bootstrap 5, Chart.js.
Лицензия: MIT.

Подробнее о распределённых проверках в MirvMon v0.9.3 →

Ссылки

Исходный код · Релизы · Установка · Скриншоты · Сообщить об ошибке


История релизов

v0.9.11 — MirvMon v0.9.11

MirvMon v0.9.11 — Unified notifications settings

Interface

The Settings → Notifications page now has a single, responsive configuration form containing three first-class delivery methods: Email (SMTP), Telegram Bot, and ChimePort.

  • The separate ChimePort footer form and its unnecessary description have been removed.
  • Global severity levels and notification cooldown appear *below all delivery methods*.
  • One Save settings button saves changes for all methods in one PostgreSQL transaction; validation failures roll back the entire form.
  • Three distinct Test Email, Test Telegram, and Test ChimePort actions save and test only the selected destination, without sending duplicate test notifications via other methods.
  • One Open notification queue link presents all deliveries and filters.
  • Existing secret fields remain masked, with blank fields preserving encrypted credentials. SMTP, Telegram and ChimePort tokens are handled independently.

Compatibility

No database migration, agent protocol change or new service is required. Legacy POST endpoints continue to work for older forms, but the current UI uses unified save and per-transport test endpoints. Existing SMTP, Telegram and ChimePort settings persist unchanged when upgrading.

Deployment

Pull/redeploy ghcr.io/mirivlad/mirvmon:0.9.11 through Portainer while keeping the existing PostgreSQL and application volumes. Check the notifications settings page and independent tests. Telegram remains enabled.

Открыть релиз на GitHub ↗

v0.9.10 — MirvMon v0.9.10

MirvMon v0.9.10 — ChimePort settings in the web UI

New admin interface

In Settings → Notifications, the dedicated ChimePort card allows administrators to enable/disable notifications, enter a server HTTPS address, configure a channel slug (e.g. servers), enter or replace the masked source token, and queue a ChimePort-only test message.

The source token is encrypted at rest in PostgreSQL using the same existing MirvMon SecretCipher and APP_KEY as the SMTP and Telegram secrets. It is never returned to the browser.

Safe upgrade and compatibility

  • New database migration 034_chimeport_web_settings.sql adds optional settings columns.
  • Previously installed v0.9.9 instances keep using the existing Docker environment settings until the administrator first saves the new form.
  • At first save, the existing token file is automatically imported and encrypted into PostgreSQL. The user does not have to reenter it.
  • Subsequently, web settings take precedence over Docker settings, including an explicit off switch.
  • SMTP and Telegram remain independent and unchanged; their settings are not overwritten by the ChimePort form.
  • Notification queue deduplication, retries and event handling are unchanged. Agent protocol stays compatible.

Deploy

After CI publishes ghcr.io/mirivlad/mirvmon:0.9.10, back up PostgreSQL and re-pull/redeploy MirvMon in Portainer with app_data and db_data preserved. Confirm /readyz, test the ChimePort-only action, and verify existing Telegram notifications.

The old token file may be retained until the web migration has been verified.

Открыть релиз на GitHub ↗

v0.9.9 — MirvMon v0.9.9

MirvMon v0.9.9 — ChimePort as a parallel notification channel

Changes

  • Optional ChimePort notifications join the existing durable outbox, independently of Telegram and email. Existing monitoring triggers, incident grouping, cooldown and deduplication remain unchanged.
  • New ChimePort transport supports HTTPS with certificate verification, non-redirecting Bearer requests, stable idempotency keys, distinct channels and 429/Retry-After backoff.
  • With CHIMEPORT_CHANNEL=servers, all MirvMon alerts and recoveries go to one user channel called Серверы (slug servers).
  • Schema migration 033_chimeport_notifications.sql safely extends notification_outbox_channel_check. Existing events and Telegram/email notification records are preserved.
  • Additional unit and integration tests, queue filter, and instructions in docs/CHIMEPORT.md.

Compatibility

  • Agent protocol and installed agents are unchanged.
  • One new SQL migration, applied by the standard migrator; use the new image after migration to ensure the worker understands ChimePort jobs.
  • New environment settings are optional; CHIMEPORT_ENABLED=0 by default.
  • Secrets must remain in a volume-mounted file readable only by the MirvMon service user, not in environment variables or source code.

Deployment

Pull and redeploy ghcr.io/mirivlad/mirvmon:0.9.9 (linux/amd64, linux/arm64) in Portainer with the existing app_data and db_data volumes intact. Follow docs/CHIMEPORT.md for token provisioning and CHIMEPORT_CHANNEL=servers. Keep Telegram enabled.

Открыть релиз на GitHub ↗

v0.9.8 — MirvMon v0.9.8

MirvMon v0.9.8 — стабильная проверка интернета и выравнивание настроек

Исправления

  • Переключение собственной сетевой связности MirvMon в offline теперь требует трёх последовательных неудачных проверок (с учётом заданного кворума). Одиночные ошибки больше не порождают ложные циклы отключения/восстановления и Telegram-спам.
  • Возврат в online подтверждается двумя последовательными успешными проверками. При прерывании серии счётчик сбрасывается.
  • Во время ожидания подтверждения прежняя запись состояния не освежается; по истечении TTL зависимые проверки безопасно видят unknown, а не ошибочный online.
  • Диагностические сообщения connectivity_probe_failed_targets содержат адреса неудавшихся проверок, классы ошибок DNS/timeout/TCP/cURL, фактическую длительность проверки и последнее подтверждённое состояние.
  • В разделе настроек кворум, интервал проверки и тайм-аут теперь расположены ровно в одну строку. Пояснение к кворуму перенесено под строку, без смещения остальных полей.
  • Добавлены регрессионные unit-тесты и руководство по диагностике.

Совместимость

Новых SQL-миграций, обязательных переменных окружения и изменений протокола агентов нет. Установленные агенты обновлять или переустанавливать не нужно.

Обновление

После успешной публикации multi-arch образа используйте ghcr.io/mirivlad/mirvmon:0.9.8 (linux/amd64, linux/arm64). В Portainer выполните Re-pull image and redeploy, сохранив тома app_data и db_data.

Настройки контроля соединения, сохранённые в интерфейсе, сохраняются при обновлении. Для сетей с нестабильным DNS можно использовать IP-адреса контрольных целей, например 1.1.1.1:443, 8.8.8.8:443, 9.9.9.9:443, кворум 2, интервал 30 секунд и тайм-аут 3 секунды. Диагностику DNS при необходимости проводите отдельно.

Открыть релиз на GitHub ↗

v0.9.7 — MirvMon v0.9.7

MirvMon v0.9.7 — security-only PHP2Shell hotfix

This supersedes the unpublished v0.9.6 candidate, which was not released because its CI contract tests still expected outdated runtime and documentation pins.

Security

  • FrankenPHP updated to 1.13.2; embedded PHP 8.5.12 closes CVE-2026-109618 and CVE-2026-109619.
  • Runtime guard prevents publishing images with vulnerable PHP.
  • Release/version and runtime contract tests updated.

Compatibility

No migrations, application API or agent protocol changes. Existing agents remain compatible.

Upgrade

Use ghcr.io/mirivlad/mirvmon:0.9.7 after GHCR publication succeeds, and re-pull/redeploy your Portainer app while keeping app_data and db_data. Verify php -r 'echo PHP_VERSION;' inside the running container is at least 8.5.12.

Открыть релиз на GitHub ↗

v0.9.5 — MirvMon v0.9.5

MirvMon v0.9.5

Что исправлено

  • Кнопка профиля пользователя в navbar теперь нормально видна в обычном состоянии: имя пользователя отображается белым, а у кнопки есть заметный светлый контур ещё до наведения курсора.
  • Для profile dropdown явно заданы Bootstrap button variables для normal, hover, focus, open и active states. Это исключает повторение регрессии из-за каскада Bootstrap.
  • Добавлен UI contract test, который фиксирует наличие явных цветов текста и рамки у кнопки профиля.

Совместимость

Схема БД, agent protocol и backend API не меняются. Новых Compose services и обязательных переменных окружения нет. Обновление агентов не требуется.

Обновление

Используйте ghcr.io/mirivlad/mirvmon:0.9.5. Достаточно обычного re-pull/redeploy image.

Открыть релиз на GitHub ↗

v0.9.4 — MirvMon v0.9.4

MirvMon v0.9.4

Что исправлено

  • Потеря Интернета у самого MirvMon больше не превращается в ложные offline/online события отдельных серверов. Новое server-offline решение теперь разрешено только когда независимый connectivity probe имеет свежий подтверждённый статус online.
  • Удалена эвристика «массовой потери агентов». Количество одновременно недоступных агентов больше не используется как признак наличия или отсутствия Интернета у центрального MirvMon.
  • Состояния connectivity offline и unknown считаются недостоверным окном наблюдения: в этот период новые offline transitions серверов не создаются, а централизованные сетевые проверки сайтов приостанавливаются.
  • После восстановления Интернета каждому агенту по-прежнему даётся его обычный offline_timeout_seconds на повторный контакт. Если агент успел вернуться, никакого ложного offline/recovery события для него не возникает.
  • После перехода connectivity offline -> online MirvMon ставит в штатный notification outbox одно системное сообщение с временем начала outage, временем восстановления и общей продолжительностью. Telegram и SMTP используют существующие глобальные настройки и retry-механику.
  • Добавлены регрессионные тесты на сценарий, когда во время outage MirvMon успел протухнуть только один агент, на системный outbox и на fail-closed поведение при неизвестном connectivity state.

Совместимость

Схема БД и agent protocol в v0.9.4 не меняются. Новых Compose services и обязательных переменных окружения нет. Обновление агентов не требуется.

Обновление

Используйте ghcr.io/mirivlad/mirvmon:0.9.4. Достаточно обычного re-pull/redeploy image; отдельной миграции нет.

Открыть релиз на GitHub ↗

v0.9.3 — MirvMon v0.9.3

MirvMon v0.9.3

Что изменилось

  • Отчёт надёжности сайтов теперь учитывает distributed quorum. Для каждой центральной автоматической проверки основного endpoint MirvMon берёт свежие результаты выбранных remote agents и применяет тот же failure quorum, который используется live incident pipeline. Missing/stale remote data не считается отказом.
  • Assertions остаются централизованными: availability считается успешной только когда quorum transport доступен и Central MirvMon подтвердил assertions.
  • В отчёте распределённые сайты явно помечаются количеством точек и quorum.
  • На вкладке События в деталях сайта добавлена компактная история точек проверки за последние 7 дней: переходы доступно/недоступно и последнее состояние каждой Central/agent точки.
  • Endpoint с auth, custom headers или allow_self_signed по-прежнему не отправляется агентам. Для такого endpoint effective quorum автоматически становится 1, поэтому отсутствие remote results не может скрыть центральный outage.
  • README, ROADMAP, technical specification и документация reliability/distributed probes синхронизированы с фактической семантикой ветки 0.9.

Совместимость

Agent protocol и схема БД в v0.9.3 не меняются. Новых Compose services и обязательных переменных окружения нет. Существующие агенты с capability website_probe_v1 продолжают работать без обновления протокола.

Обновление

Используйте ghcr.io/mirivlad/mirvmon:0.9.3. Обычного обновления image достаточно; отдельной миграции для v0.9.3 нет.

Открыть релиз на GitHub ↗

v0.9.2 — MirvMon v0.9.2

MirvMon v0.9.2

Что изменилось

  • Central MirvMon теперь всегда участвует в проверке сайта. В форме распределённых проверок больше нет отдельного выбора центральной точки: администратор выбирает только дополнительные агентские probe points.
  • Добавлена миграция 032_central_website_probe_invariant.sql: существующие сайты с отключённой центральной точкой автоматически переводятся в central_probe_enabled = TRUE, а схема БД больше не допускает обратное состояние.
  • Семантика распределённых проверок зафиксирована окончательно: агенты выполняют только transport HTTP(S)-проверку. TLS expiry, срок регистрации домена, content/status assertions и performance assertions остаются централизованными функциями MirvMon.
  • Убрано служебное пояснение про «первую версию» remote probes из пользовательской формы.
  • Карточка «Всего серверов» на главном обзоре теперь кликабельна и снимает статусный фильтр, возвращая полный список серверов.
  • В отчёте надёжности доступность сайтов показывается сразу по имеющимся автоматическим проверкам. Если полнота выбранного периода ниже 95%, результат помечается как «Неполный период», но само значение availability больше не скрывается. Для серверов прежний строгий критерий полноты сохранён.
  • Для всех локальных CSS/JS assets добавлен cache-busting по APP_VERSION. После обновления MirvMon браузер получает актуальные стили и скрипты без ручного Ctrl+R.

Совместимость

Agent protocol в v0.9.2 не менялся. Remote agents по-прежнему используют capability website_probe_v1 и передают только transport HTTP(S) observations.

Версия содержит одну миграцию БД. Она автоматически исправляет старые сайты с отключённым Central MirvMon и закрепляет Central как обязательную точку проверки.

Обновление

Используйте ghcr.io/mirivlad/mirvmon:0.9.2. Новых Compose services и обязательных переменных окружения нет; миграция применяется штатным механизмом MirvMon при запуске.

Открыть релиз на GitHub ↗

v0.9.1 — MirvMon v0.9.1

MirvMon v0.9.1

Что изменилось

  • В списке серверов и в обзоре агентов появились быстрые переключатели «Проверки сайтов». Поддерживающий website_probe_v1 агент можно сразу разрешить или запретить как probe point без захода в его настройки.
  • Для старых агентов без website_probe_v1 переключатель недоступен и прямо показывает, что требуется обновление. Если отключаемая точка уже назначена сайтам, MirvMon предупреждает об этом, снимает назначения и безопасно корректирует quorum.
  • Карточки на /sites теперь показывают состояние выбранных probe points: зелёная точка — endpoint доступен, красная — transport failure, серая — свежих данных нет. Central MirvMon визуально отличается кольцом.
  • Рядом с точками добавлен отдельный quorum-индикатор: число текущих отказов сравнивается с числом отказов, необходимым для aggregate failure. Это позволяет увидеть состояние распределённой проверки прямо из списка сайтов.
  • Свежесть точек на карточке использует ту же семантику, что и сам quorum: max(120 секунд, 3 × interval endpoint). Старый успешный результат не остаётся зелёным бесконечно.
  • Верхняя навигация переработана: Серверы теперь раскрываются в Список серверов / Группы серверов / Агенты.
  • Раздел Настройки целиком перенесён из основной навигации в dropdown пользователя.
  • В подменю Аналитика добавлены те же иконки, что используются в заголовках соответствующих страниц.
  • Активный раздел сохраняет прежнюю подсветку пункта меню, а его иконка получает стабильный цвет раздела. Неактивные иконки остаются светлыми.

Совместимость

Изменений схемы БД и agent protocol в v0.9.1 нет. Распределённые проверки используют введённую в v0.9.0 capability website_probe_v1; старые агенты продолжают работать как раньше, но не могут быть включены как remote probe point до обновления.

Обновление

Используйте ghcr.io/mirivlad/mirvmon:0.9.1. Новых Compose services, обязательных переменных окружения и миграций нет.

Открыть релиз на GitHub ↗

Источник: GitHub Releases · данные кэшируются на сервере.