Monit: পড়ে যাওয়া সেবা আবার চালানো এবং এই উপায়ের সীমা

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-এর তিনটি পুনরারম্ভ এমন একটা নির্ণয় যা নইলে নজরের বাইরে চলে যেত, কারণ সাইট সারাক্ষণ চলছিল।

তাই দেখার জিনিস বর্তমান অবস্থা নয় — সেটি প্রায় সবসময় সবুজ — বরং ইতিহাস: গত সপ্তাহে কতবার কিছু নিজে থেকে উঠেছে। এক পাতায় এটি কেমন দেখায় তা নিচের ডেমোতে।