Monit на VDS: перезапуск сервисов, проверки и алерты за 30 минут

Если нужно быстро навести базовый порядок на сервере и получить минимум мониторинга (monitoring) с возможностью автоматического перезапуска (restart) упавших процессов (processes), Monit — идеальный инструмент. Он прост, не требует базы данных, потребляет считанные мегабайты и умеет сам принимать решения: перезапустить сервис, прислать alerts, размониторить шумный ресурс. Если сервера ещё нет — удобно стартовать с VDS и пройтись по шагам ниже.

Что такое Monit и чем он полезен на VDS

Monit — это маленький агент, который по заданным правилам следит за состоянием системы: процессов по pidfile, портов и протоколов, файлов и директорий, загрузки CPU и RAM, места на диске. При отклонениях он может отправить alerts (почта, команда, лог) и/или выполнить действие: перезапуск сервиса, перезагрузка машины, запуск произвольного скрипта. Для VDS это «подушка безопасности», когда Prometheus и прочие сложные стеки пока «в пути», а прямо сейчас нужно быстро закрыть риски простоев.

Monit не заменяет полноформатный мониторинг, но отлично закрывает «SRE‑минимум»: раннее обнаружение падения критичных процессов и попытку лечения в автомате.

Что будем делать за 30 минут

• Установим Monit из пакетов и включим автозапуск.
• Отредактируем базовый конфиг: интервал опроса, логирование, почтовые alerts.
• Добавим проверки: nginx, php-fpm, sshd, system load, свободное место, порты.
• Настроим безопасный веб‑интерфейс Monit на локалхосте.
• Разберём типичные ошибки и защиту от рестарт‑циклов.

Установка на популярных дистрибутивах

Debian/Ubuntu

sudo apt update
sudo apt install -y monit
sudo systemctl enable --now monit
monit -V

AlmaLinux/Rocky/Oracle (RHEL‑семейство)

sudo dnf install -y monit
sudo systemctl enable --now monit
monit -V

После старта проверьте статус демона и отсутствие ошибок в логах:

systemctl status monit
sudo journalctl -u monit -n 50 --no-pager

Базовая конфигурация: цикл, логи, алерты

Главный файл обычно лежит в /etc/monit/monitrc. На Debian‑семействе включён include для каталогов conf.d/conf-enabled. Начнём с минимально полезного:

set daemon 30
set logfile syslog
set idfile /var/lib/monit/id
set statefile /var/lib/monit/state
set eventqueue
    basedir /var/lib/monit/events
    slots 100

set mailserver localhost
set mail-format { from: monit@localhost }
set alert admin@example with reminder on 10 cycles

# Веб‑интерфейс только на локалхосте (пробрасывайте туннелем при необходимости)
set httpd port 2812 and
    use address 127.0.0.1
    allow 127.0.0.1
    allow user:strongpassword

include /etc/monit/conf.d/*

Проверка синтаксиса и перезагрузка Monit

sudo monit -t
sudo monit reload
monit summary

Команда monit -t проверяет конфиг, monit reload перечитывает его без рестарта демона, monit summary показывает краткое состояние всех проверок.

Проверки процессов и портов: nginx, php-fpm, sshd

Разбиваем конфиг по файлам в /etc/monit/conf.d/ — так проще сопровождать. Начнём с веб‑стека.

nginx

sudo sh -c 'cat > /etc/monit/conf.d/nginx.monit' << "EOF"
check process nginx with pidfile /run/nginx.pid
    start program = "/bin/systemctl start nginx"
    stop program  = "/bin/systemctl stop nginx"
    if failed port 80 protocol http request "/" then restart
    if failed port 443 type TCPSSL for 2 cycles then restart
    if totalmem > 500 MB for 3 cycles then alert
    if 5 restarts within 5 cycles then timeout
EOF
sudo monit -t
sudo monit reload
monit status nginx

• check process с pidfile даёт Monit способ узнать, жив ли nginx.
• Проверяем 80/tcp как HTTP и 443/tcp как TCPSSL; если два цикла подряд нет ответа — делаем restart.
• Ограничиваем память и вводим timeout: если сервис рестартует слишком часто, Monit прекратит попытки и пришлёт alert, чтобы вы не попали в бесконечный цикл.

PHP‑FPM

sudo sh -c 'cat > /etc/monit/conf.d/php-fpm.monit' << "EOF"
check process php-fpm with pidfile /run/php/php-fpm.pid
    start program = "/bin/systemctl start php-fpm"
    stop program  = "/bin/systemctl stop php-fpm"
    if failed unixsocket /run/php/php-fpm.sock then restart
    if cpu > 90% for 5 cycles then alert
    if 5 restarts within 5 cycles then timeout
EOF
sudo monit -t
sudo monit reload
monit status php-fpm

Используйте правильные пути для вашего дистрибутива/версии PHP: где‑то это /run/php/php8.2-fpm.sock и php8.2-fpm.service.

sshd (на всякий случай)

sudo sh -c 'cat > /etc/monit/conf.d/sshd.monit' << "EOF"
check process sshd with pidfile /run/sshd.pid
    start program = "/bin/systemctl start sshd"
    stop program  = "/bin/systemctl stop sshd"
    if failed port 22 protocol ssh for 2 cycles then restart
    if 3 restarts within 5 cycles then timeout
EOF
sudo monit -t
sudo monit reload

Так вы снижаете риск потерять доступ из‑за подвисшего демона. Но не забывайте, что firewall тоже может быть причиной; Monit тут не поможет.

Системные метрики: load average, память, диск

Мониторим ключевые системные границы. Это alerts‑уровень (без restart), чтобы не лечить симптомы перезапуском, когда причина — ресурсы.

sudo sh -c 'cat > /etc/monit/conf.d/system.monit' << "EOF"
check system $HOST
    if loadavg(1min) > 4 for 3 cycles then alert
    if memory usage > 85% for 5 cycles then alert
    if swap usage > 20% for 5 cycles then alert
    if cpu usage (user) > 85% for 5 cycles then alert

check filesystem rootfs with path /
    if space usage > 85% then alert
    if inode usage > 85% then alert
EOF
sudo monit -t
sudo monit reload

Порог loadavg подберите под вашу VDS: ориентируйтесь на число vCPU. Для 2 vCPU разумно начать с 3–4.

Проверка TCP‑порта без процесса

Если у вас внешний сервис или контейнер, который поднимает порт, можно мониторить сам порт.

sudo sh -c 'cat > /etc/monit/conf.d/port-redis.monit' << "EOF"
check host redis-local with address 127.0.0.1
    if failed port 6379 type tcp for 2 cycles then alert
EOF
sudo monit -t
sudo monit reload

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Антипаттерны и защита от рестарт‑петлей

• Всегда указывайте if N restarts within M cycles then timeout для каждого сервиса. Это ключ к устойчивости.
• Не перезапускайте сервис при системных алертах (диск, RAM). Сначала разберитесь с причиной, иначе получите flap.
• Соблюдайте «двойное подтверждение»: for 2 cycles, for 3 cycles на сетевых проверках.
• Тщательно выбирайте pidfile. Неверный путь приведёт к ложным рестартам.

Почтовые alerts: быстро и по делу

В примере выше alerts отправляются на admin@example через локальный MTA. Если MTA не настроен, поставьте минимальную отправку почты или перенаправьте в syslog пока без e‑mail. Формат сообщений настраивается опцией set mail-format. Рекомендую краткие темы, чтобы фильтровать инциденты в почтовом клиенте.

set mail-format {
  from: monit@localhost
  subject: [Monit][$HOST] $EVENT $SERVICE
  message: $EVENT on $HOST at $DATE
}

set alert admin@example not on { instance }

Веб‑интерфейс Monit: безопасный доступ

Мы уже включили set httpd port 2812 на 127.0.0.1. Для доступа с рабочего места используйте SSH‑туннель. Не открывайте порт наружу. UI удобен для ручного старта/стопа, просмотра логики перезапуска, графиков нагрузок за последние циклы.

ssh -L 2812:127.0.0.1:2812 user@your-vds

Скрипты действий: аккуратно расширяем

Monit может выполнять произвольные команды: отправить hooks в ваш инцидент‑трекер, перегенерировать конфиг, пересобрать кэш. Используйте exec в условиях:

check process queue-worker with pidfile /var/run/worker.pid
    start program = "/bin/systemctl start queue-worker"
    stop program  = "/bin/systemctl stop queue-worker"
    if 3 restarts within 5 cycles then exec "/usr/local/bin/escalate.sh" as uid root and gid root
    if 5 restarts within 5 cycles then timeout

Скрипт должен быть идемпотентным и безопасным. Всегда логируйте в syslog, чтобы понимать, что именно сделал Monit.

Диагностика: где искать правду

• monit status и monit summary — текущее состояние и последние события.
• Журналы: journalctl -u monit и системный syslog.
• monit reload после каждой правки, monit -t перед этим — обязательны.
• Проверяйте права на pidfile и наличие systemctl в путях, указанных в start/stop program.

Точные пороги и цикл опроса

Интервал set daemon подбирайте под SLA сервиса и RTO. Для публичного сайта 30 секунд — разумный компромисс между скоростью реакции и шумом. Пороги CPU/RAM задавайте «за несколько шагов» до насыщения, чтобы оставалось время на реакцию. Для портов используйте «двойной удар» (for 2 cycles), чтобы сгладить кратковременные сетевые Glitch.

Чек‑лист «за 30 минут»

1. Установить Monit и включить автозапуск.
2. Задать set daemon 30, логи, set httpd на 127.0.0.1, alerts.
3. Добавить проверки nginx, php-fpm, sshd с restart и timeout.
4. Добавить системные алерты по load/memory/disk.
5. Проверить конфиг: monit -t, затем monit reload.
6. Посмотреть monit summary и имитацией отказа убедиться, что происходит корректный restart и приходят alerts.

Расширение: шаблоны для типовых сервисов

MariaDB/MySQL

check process mariadb with pidfile /run/mysqld/mysqld.pid
    start program = "/bin/systemctl start mariadb"
    stop program  = "/bin/systemctl stop mariadb"
    if failed port 3306 protocol mysql for 2 cycles then restart
    if 5 restarts within 5 cycles then timeout

Node.js через systemd

check process nodeapp matching ".*node.*app.js"
    start program = "/bin/systemctl start nodeapp"
    stop program  = "/bin/systemctl stop nodeapp"
    if failed port 3000 type tcp for 2 cycles then restart
    if 5 restarts within 5 cycles then timeout

Безопасность

• Не публикуйте Monit UI наружу. Держите на 127.0.0.1 и используйте SSH‑туннель.
• Храните конфиги с правами 600, так как там могут быть креды.
• Ограничивайте действия: давайте Monit только нужные команды start/stop.
• Логи и почту — без лишних персональных данных; в темах достаточно имени хоста и сервиса.

Итог

Monit — быстрый и надёжный способ дать вашей VDS базовый monitoring и авто‑восстановление без тяжёлой инфраструктуры. За полчаса вы получаете контроль над ключевыми processes, автоматический restart при сбое и информативные alerts. Дальше остаётся только подкрутить пороги под реальные нагрузки и постепенно расширять покрытие — от портов и демонов до очередей и фоновых воркеров.

Если предпочитаете администрирование через панели, посмотрите сравнительный обзор панелей для VDS: сравнение панелей для VDS в 2025. А для продвинутой маршрутизации алертов и шаблонов пригодится материал про Alertmanager: маршрутизация, silence и шаблоны.