Monit стежить, щоб служби працювали, і піднімає їх, коли вони падають. Перше справедливе питання: навіщо, якщо systemd робить те саме одним рядком Restart=always?
Відповідь визначає всю схему. systemd бачить, що процес завершився, і запускає його знову. Він не знає, чи відповідає служба на запити. PHP-FPM, який вичерпав ліміт процесів, для systemd живий і здоровий, а сайт при цьому віддає 502. MySQL, у якої закінчилося місце на диску, продовжує працювати як процес і не виконує жодного запиту. Monit перевіряє не факт існування процесу, а його поведінку: чи відповідає порт, що повертає HTTP-запит, скільки пам’яті використовується.
Звідси правило: залиште systemd як є й додайте Monit для функціональних перевірок. Дублювати перезапуск процесу, що впав, немає сенсу.
Конфігурація
sudo apt install monit
Основний файл — /etc/monit/monitrc; власні перевірки йдуть окремими файлами в /etc/monit/conf.d/. Звичайний початок:
set daemon 60
set logfile /var/log/monit.log
set mailserver localhost
set alert admin@example.com
Опитування раз на хвилину — розумний баланс. Частіше додає навантаження й підвищує ризик хибного перезапуску через односекундну затримку.
Вебінтерфейс: лише локально
У Monit є вбудована вебсторінка, і вмикають її зазвичай приблизно так, як показує перший знайдений посібник, — на всіх адресах. Результат — панель керування службами сервера, доступна з інтернету. Правильний варіант:
set httpd port 2812 and
use address localhost
allow localhost
allow admin:'a-long-password'
Доступ ззовні — через SSH-тунель:
ssh -L 2812:localhost:2812 user@203.0.113.25
Після цього сторінка відкривається на вашому комп’ютері за адресою localhost:2812, і назовні не дивиться нічого.
Перевірки, які мають сенс
Вебсервер — не за фактом процесу, а за його відповіддю:
check process nginx with pidfile /run/nginx.pid
start program = "/bin/systemctl start nginx"
stop program = "/bin/systemctl stop nginx"
if failed host 127.0.0.1 port 80 protocol http
request "/" status = 200
for 3 cycles then restart
if 3 restarts within 10 cycles then unmonitor
Три рядки тут важливіші за решту.
protocol http ... status = 200 — це та перевірка, заради якої все й налаштовувалося: сервер має віддати сторінку, а не просто тримати порт відкритим.
for 3 cycles означає не реагувати на одну-єдину невдачу. Без цього Monit перезапустить службу через одну повільну відповідь під навантаженням, а це лише погіршить справи.
if 3 restarts within 10 cycles then unmonitor — обов’язковий рядок. Якщо служба не піднімається через помилку в конфігурації, Monit перезапускатиме її вічно, додаючи навантаження й забиваючи журнали. Цей рядок означає: три невдалі спроби — зупинись і залиш повідомлення. Далі потрібна людина; автоматика вже не допоможе.
Місце на диску перевіряють узагалі без автоматики, просто як сповіщення:
check filesystem rootfs with path /
if space usage > 85% then alert
if inode usage > 85% then alert
Рядок про inode потрібен окремо: вони вичерпуються незалежно від місця, і без нього ця ситуація проходить непоміченою.
Перевірка конфігурації
sudo monit -t
sudo systemctl reload monit
sudo monit summary
sudo monit status
monit -t перевіряє синтаксис до застосування. monit summary дає коротку таблицю станів — місце, з якого починають розбір будь-якої проблеми.
І перевірте, що пошта надсилається. Monit повідомляє про події листом, і якщо доставку не налаштовано, жодного сповіщення не буде: служба перезапуститься, а ви про це не дізнаєтеся — тоді як повторні перезапуски і є головним сигналом. Їх видно і в журналі: /var/log/monit.log.
Чого Monit не робить
Він не усуває причину. Перезапуск — це відстрочка, а служба, яку постійно перезапускають, означає, що десь бракує пам’яті, або закінчується місце, або застосунок тече. Цінність інструмента не в перезапуску, а в лічильнику: три перезапуски nginx за добу — це діагноз, який інакше пройшов би непоміченим, бо сайт увесь час працював.
Тож дивитися треба не на поточний стан — він майже завжди зелений, — а на історію: скільки разів за минулий тиждень щось піднялося саме. Який вигляд це має на одній сторінці, показує демо нижче.