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 کے تین دوبارہ آغاز ایک ایسی تشخیص ہے جو ورنہ بغیر توجہ کے گزر جاتی، کیونکہ سائٹ سارا وقت چل رہی تھی۔
لہٰذا دیکھنے کی چیز موجودہ حالت نہیں — وہ تقریباً ہمیشہ سبز ہوتی ہے — بلکہ تاریخ ہے: گزشتہ ہفتے کتنی بار کچھ خود سے اٹھا۔ یہ ایک صفحے پر کیسا لگتا ہے، نیچے ڈیمو دکھاتا ہے۔