Monit پایش می‌کند که سرویس‌ها کار کنند و وقتی می‌افتند بازشان می‌گرداند. نخستین پرسش بجا: چرا، وقتی systemd همین کار را با یک سطر Restart=always می‌کند؟

پاسخ تمام چیدمان را تعیین می‌کند. systemd می‌بیند که فرایندی پایان یافته و دوباره اجرایش می‌کند. اما نمی‌داند که آیا سرویس به درخواست‌ها پاسخ می‌دهد. PHP-FPM که به سقف فرایندهایش رسیده برای systemd زنده و سالم است، حال آنکه سایت ۵۰۲ برمی‌گرداند. 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 در یک شبانه‌روز تشخیصی است که وگرنه نادیده می‌گذشت، چون سایت تمام مدت کار می‌کرد.

پس آنچه باید دید وضعیت کنونی نیست — که تقریباً همیشه سبز است — بلکه تاریخچه است: در هفته گذشته چند بار چیزی خودبه‌خود بلند شده است. شکل این در یک صفحه را نمایش پایین نشان می‌دهد.