يراقب 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

وسطر الـ inodes مطلوب على حدة: فهي تنفد بمعزل عن المساحة، وبدونه يمرّ هذا الوضع دون ملاحظة.

فحص الإعداد

sudo monit -t
sudo systemctl reload monit
sudo monit summary
sudo monit status

يفحص monit -t الصياغة قبل تطبيقها. ويعطي monit summary جدولًا موجزًا للحالات — وهو الموضع الذي يُبدأ منه فحص أي مشكلة.

وتحقّق أن البريد يُرسل. فـ Monit يبلّغ عن الأحداث برسالة، وإن لم يُضبط التسليم فلن يكون هناك أي إشعار: ستُعاد الخدمة إلى التشغيل ولن تعرف بذلك — بينما تكرار إعادة التشغيل هو الإشارة الأساسية بالذات. وهي تُرى في السجل أيضًا: /var/log/monit.log.

ما لا يفعله Monit

هو لا يزيل السبب. فإعادة التشغيل تأجيل، وخدمة يُعاد تشغيلها باستمرار تعني أن الذاكرة تنقص في مكان ما، أو أن المساحة تنفد، أو أن التطبيق يسرّب. وقيمة الأداة ليست في إعادة التشغيل بل في العدّاد: فثلاث عمليات إعادة تشغيل لـ nginx في يوم تشخيص كان سيمرّ دون ملاحظة، لأن الموقع كان يعمل طوال الوقت.

فما ينبغي النظر إليه ليس الحالة الراهنة — وهي خضراء دائمًا تقريبًا — بل التاريخ: كم مرة نهض شيء من تلقاء نفسه خلال الأسبوع الماضي. وشكل ذلك على صفحة واحدة يعرضه العرض التوضيحي أدناه.