سائٹ ڈاؤن ٹائم الرٹس

پینل میں گراف مشین کی حالت دکھاتے ہیں، لیکن یہ سوال کا جواب نہیں دیتے کہ ”سائٹ اپ ہے یا نہیں؟“ ایپلیکیشن CPU کے خالی بیٹھے ہونے کے باوجود ہینگ ہو سکتی ہے، اور بیرونی جانچ کے بغیر آپ کو اس کا علم اپنے کلائنٹس سے ہوگا۔

بیرونی جانچ

بنیادی اصول: جس مشین کی نگرانی کر رہے ہیں، اسی سے جانچ نہ کریں۔ کوئی بھی بیرونی اپ ٹائم مانیٹرنگ سروس استعمال کریں — ایسی بہت سی ہیں، جن میں کئی ایڈریسز کے لیے ایک منٹ کے وقفے کے ساتھ مفت پلانز بھی شامل ہیں۔ وہ سیٹنگز جو واقعی اہم ہیں:

• جانچ کا ایڈریس۔ ہوم پیج نہیں، بلکہ /healthz جیسا الگ روٹ جو ڈیٹا بیس اور قطار دونوں کی جانچ کرے۔ ورنہ کیش شدہ ہوم پیج بیک اینڈ کے مردہ ہونے پر بھی پیش ہوتا رہے گا۔
• متوقع جواب۔ 200 کوڈ کے ساتھ باڈی میں ایک سب سٹرنگ۔ بہت سی ایپلیکیشنز خراب ہونے پر غلطی کے پیغام کے ساتھ 200 واپس کرتی ہیں۔
• تھریش ہولڈ۔ لگاتار دو یا تین ناکام کوششیں، ورنہ نیٹ ورک کی کوئی بھی ہچکی آپ کو جگا دے گی۔
• چینل۔ Telegram یا ای میل۔ یقینی بنائیں کہ الرٹ واقعی پہنچتا ہے: سروس کو ایک منٹ کے لیے بند کریں اور پیغام کا انتظار کریں۔

سرٹیفکیٹ کی میعاد ختم ہونے کی الگ جانچ نہ بھولیں — میعاد ختم شدہ TLS سرٹیفکیٹ آؤٹیج جیسا لگتا ہے اور باقاعدگی سے ہوتا ہے۔

مشین پر ہی واچ ڈاگ

بیرونی مانیٹرنگ آپ کو بتائے گی کہ سائٹ ڈاؤن ہے۔ اسے خود بخود واپس آنے کے لیے systemd کنفیگر کریں۔ سروس یونٹ میں:

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

اس طرح سروس حادثاتی کریش سے بچ جائے گی، لیکن کنفیگریشن خراب ہونے پر لامحدود لوپ میں نہیں پھنے گی۔ ترمیم کے بعد: systemctl daemon-reload && systemctl restart myapp۔

ان ایپلیکیشنز کے لیے جو کریش نہیں ہوتیں بلکہ ہینگ ہو جاتی ہیں، ایک HTTP جانچ شامل کریں۔ یونٹس کا ایک جوڑا — ایک ٹائمر اور ایک سروس:

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

اسکرپٹ خود:

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

مشین کی صحت کے الرٹس

آؤٹیج سے پہلے ڈسک اسپیس اور میموری ختم ہونے کا علم ہونا بھی مفید ہے۔ سب سے آسان آپشن ایک cron جاب ہے جو تھریش ہولڈ سے تجاوز پر Telegram پیغام بھیجے:

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="VDS disk usage is over 85%"

تیار تھریش ہولڈز کے ساتھ زیادہ جدید آپشن Netdata فراہم کرتا ہے۔

عام غلطیاں

• اسی مشین پر مانیٹرنگ۔ مشین ڈاؤن ہوئی تو واچ ڈاگ اور الرٹنگ دونوں مر جائیں گے۔
• حد سے زیادہ حساس تھریش ہولڈ۔ جھوٹے الرٹس کا سیلاب مطلب ہے کہ آپ اصل والے سے بھی گزر جائیں گے۔
• وجہ کی چھان بین کے بجائے Restart=always۔ ری اسٹارٹ میموری لیک کو چھپا دیتا ہے: سروس ہر آدھے گھنٹے میں کریش ہوتی ہے، اور آپ کو نظر نہیں آتا۔ systemctl show myapp -p NRestarts اور journal دیکھیں۔
• صرف ping کے ذریعے جانچ۔ مشین مکمل طور پر مردہ ویب سرور کے ساتھ بھی ICMP کا جواب دیتی ہے۔

الرٹ بجنے پر سب سے پہلے پینل /hosting/vds/m/<id> میں ”Overview“ دیکھیں۔ گراف میں وقفہ مشین میں مسئلے کی نشاندہی کرتا ہے؛ سائٹ کے دستیاب نہ ہونے پر بھی فلیٹ گراف ایپلیکیشن میں مسئلے کی نشاندہی کرتے ہیں۔