سرور اپ ٹائم کی نگرانی اور الرٹس ترتیب دینے کا طریقہ

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

"اپ ٹائم مانیٹرنگ" کا اصل میں کیا مطلب ہے

اپ ٹائم مانیٹرنگ دو مختلف سوالات کا جواب دیتی ہے، اور ایک قابلِ اعتماد سروس چلانے کے لیے آپ کو دونوں کی ضرورت ہے:

• کیا میرا سرور باہر سے قابلِ رسائی ہے؟ (بیرونی/بلیک باکس مانیٹرنگ) — کیا انٹرنیٹ پر موجود کوئی حقیقی کلائنٹ صحت مند ردِعمل حاصل کرتا ہے؟
• کیا میرا سرور اندر سے صحت مند ہے؟ (اندرونی/وائٹ باکس مانیٹرنگ) — CPU، میموری، ڈسک، اور انفرادی سروسز جیسے Nginx، MySQL، یا آپ کا ایپ پروسیس۔

بیرونی چیکس وہ خرابیاں پکڑتے ہیں جو آپ کے صارفین کو نظر آتی ہیں۔ اندرونی چیکس وجوہات پکڑتے ہیں — ڈسک کا بھر جانا، بے قابو پروسیس، سواپ تھریشنگ — اکثر اس سے پہلے کہ یہ کسی خرابی میں تبدیل ہوں۔ یہ رہنمائی ایک لینکس VPS پر دونوں ترتیب دیتی ہے، نیز ایسی الرٹنگ جو آپ تک سیکنڈوں میں پہنچتی ہے۔ کمانڈز یہ فرض کرتی ہیں کہ آپ Skyline Cloud سرور پر Ubuntu 22.04/24.04 یا Debian استعمال کر رہے ہیں؛ AlmaLinux/RHEL کے لیے پیکیج ناموں کو ڈھال لیں۔

مرحلہ 1 — بیرونی اپ ٹائم چیکس

سب سے سادہ بیرونی چیک آپ کے سرور کے علاوہ کسی مشین سے ایک HTTP درخواست ہے۔ سائٹ کے جواب دینے کی تصدیق کے لیے اسے کسی دوسرے ہوسٹ (یا اپنے لیپ ٹاپ) سے چلائیں:

curl -sS -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
  https://example.com/

ایک صحت مند نتیجہ کچھ یوں نظر آتا ہے HTTP 200 in 0.184s۔ کوڈ لکھے بغیر مسلسل نگرانی کے لیے، UptimeRobot جیسا کوئی ہوسٹڈ چیکر یا Uptime Kuma جیسا کوئی سیلف ہوسٹڈ ٹول استعمال کریں۔ سیلف ہوسٹنگ آپ کا مانیٹرنگ ڈیٹا مملکت کے اندر رکھتی ہے — جو PDPL اور NCA کی مطابقت کے لیے مفید ہے۔

Uptime Kuma کو ایک الگ، چھوٹے VPS پر چلائیں (کبھی اس سرور پر نہیں جس کی یہ نگرانی کرتا ہے) Docker کا استعمال کرتے ہوئے:

docker run -d --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

http://<monitor-ip>:3001 کھولیں، اپنا ایڈمن اکاؤنٹ بنائیں، پھر Add New Monitor:

• Monitor Type: HTTP(s)
• URL: https://example.com/health (ہوم پیج نہیں، بلکہ ایک ہلکا پھلکا ہیلتھ اینڈ پوائنٹ استعمال کریں)
• Heartbeat Interval: 60 سیکنڈ
• Retries: 2 (ایک ہی لمحاتی جھٹکے پر الرٹ سے بچاتا ہے)
• Accepted Status Codes: 200-299

ہمیشہ ایک مخصوص /health اینڈ پوائنٹ کی نگرانی کریں جو تصدیق کرے کہ آپ کی ایپ اور اس کا ڈیٹابیس چالو ہیں، نہ کہ صرف یہ کہ ویب سرور کوئی صفحہ واپس کرتا ہے۔

مرحلہ 2 — node_exporter اور ایک چیک اسکرپٹ کے ساتھ اندرونی صحت

ایک واحد سرور کے لیے، آپ کو مکمل Prometheus اسٹیک کی ضرورت نہیں ہے۔ cron یا systemd timer کے ذریعے چلائی جانے والی ایک مختصر اسکرپٹ بنیادی ضروریات پوری کرتی ہے۔ /usr/local/bin/health-check.sh بنائیں:

#!/usr/bin/env bash
set -euo pipefail

THRESH_DISK=90      # percent
THRESH_MEM=90       # percent
WEBHOOK="https://hooks.example.com/your-webhook"

alert() {
  curl -fsS -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"[$(hostname)] $1\"}" "$WEBHOOK" || true
}

# Disk usage on /
disk=$(df --output=pcent / | tail -1 | tr -dc '0-9')
[ "$disk" -ge "$THRESH_DISK" ] && alert "Disk at ${disk}% on /"

# Memory usage
mem=$(free | awk '/Mem:/ {printf "%d", $3/$2*100}')
[ "$mem" -ge "$THRESH_MEM" ] && alert "Memory at ${mem}%"

# Critical service must be active
for svc in nginx mysql; do
  systemctl is-active --quiet "$svc" || alert "Service $svc is DOWN"
done

اسے قابلِ عمل بنائیں اور آزمائیں:

sudo chmod +x /usr/local/bin/health-check.sh
sudo /usr/local/bin/health-check.sh

اسے ایک systemd timer کے ساتھ شیڈول کریں، جو لاگنگ اور چھوٹے ہوئے رنز کو سنبھالنے کے لیے cron سے زیادہ قابلِ اعتماد ہے۔ /etc/systemd/system/health-check.service بنائیں:

[Unit]
Description=Server health check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh

اور /etc/systemd/system/health-check.timer:

[Unit]
Description=Run health check every 2 minutes

[Timer]

[Install]
WantedBy=timers.target

اسے فعال کریں:

sudo systemctl daemon-reload
sudo systemctl enable --now health-check.timer
systemctl list-timers health-check.timer

زیادہ تفصیلی میٹرکس اور تاریخ کے لیے، Prometheus node_exporter انسٹال کریں، جو CPU، میموری، ڈسک، اور نیٹ ورک کو پورٹ 9100 پر میٹرکس کے طور پر ظاہر کرتا ہے:

sudo apt update && sudo apt install -y prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter
curl -s http://localhost:9100/metrics | head

اسے localhost سے منسلک کریں یا اپنی فائر وال میں پورٹ 9100 کو محدود کریں تاکہ میٹرکس عوامی نہ ہوں:

sudo ufw allow from <monitor-ip> to any port 9100 proto tcp

مرحلہ 3 — ایسی الرٹنگ جو واقعی آپ تک پہنچے

ایک الرٹ تبھی مفید ہے جب وہ تیزی سے اور ایک سے زائد چینل کے ذریعے پہنچے۔ کم از کم دو ترتیب دیں تاکہ کسی ایک ناکام فراہم کنندہ کی وجہ سے آپ خاموش نہ ہو جائیں۔

الرٹ ای میل ایک مناسب SMTP ریلے کے ذریعے بھیجیں — کبھی بھی زیرِ نگرانی سرور کے اپنے میل پر انحصار نہ کریں، کیونکہ اگر سرور ڈاؤن ہو تو وہ آپ کو خبردار نہیں کر سکتا۔ بزنس ای میل ہوسٹنگ یا کوئی بھی SMTP فراہم کنندہ استعمال کریں۔ ایک کم سے کم msmtp پر مبنی ای میل الرٹ:

sudo apt install -y msmtp msmtp-mta
printf 'Subject: ALERT %s\n\n%s\n' "$(hostname)" "Disk high" \
  | msmtp -a default you@example.com

Uptime Kuma میں، Settings → Notifications کے تحت اطلاعات شامل کریں (Email/SMTP، Slack، Telegram، یا ایک جنرک ویب ہک) اور انہیں ہر مانیٹر کے ساتھ منسلک کریں۔

مرحلہ 4 — حدود کو ٹیون کریں اور الرٹ تھکاوٹ سے بچیں

بری الرٹنگ کوئی الرٹنگ نہ ہونے سے بھی بدتر ہے — لوگ اسے نظر انداز کرنا سیکھ لیتے ہیں۔ ان اصولوں پر عمل کریں:

• الرٹ سے پہلے 2 یا زائد ناکام چیکس کا تقاضا کریں (Retries سیٹنگ) تاکہ لمحاتی جھٹکے نظر انداز ہو جائیں۔
• ان علامات پر الرٹ دیں جو صارفین محسوس کرتے ہیں، جیسے HTTP 5xx یا زیادہ لیٹنسی، نہ کہ ہر اندرونی میٹرک پر۔
• معقول حدود مقرر کریں: 90% ڈسک، 90% میموری مسلسل، آپ کی معمول کی p95 سے زائد لیٹنسی۔
• ایک ریکوری اطلاع بھیجیں تاکہ آپ کو معلوم ہو کہ مسئلہ کب حل ہوا۔
• الرٹس کا ماہانہ جائزہ لیں اور جو بھی جھوٹا الارم دیتا رہا اسے حذف یا ٹیون کریں۔

پوری پائپ لائن کی تصدیق کریں

اس پر انحصار کرنے سے پہلے الرٹ کے راستے کی سرے سے سرے تک جانچ کریں۔ عارضی طور پر کوئی حد کم کریں یا کوئی غیر اہم سروس روک دیں:

sudo systemctl stop nginx        # triggers the service-down alert
# confirm the alert arrives, then:
sudo systemctl start nginx

اگر الرٹ چند منٹوں کے اندر آپ کے ان باکس اور چیٹ میں پہنچ جاتا ہے، تو آپ کی نگرانی حقیقی ہے۔ ایک غیر آزمائی شدہ الرٹ پائپ لائن بالکل ویسی ہی ہے جیسے کوئی نگرانی نہ ہو۔

اختتامیہ

اب آپ کے پاس بیرونی اپ ٹائم چیکس، systemd timer اور node_exporter کے ذریعے اندرونی صحت کی نگرانی، اور کثیر چینل الرٹنگ ہے جس کی آپ نے واقعی تصدیق کر لی ہے۔ اپنے مانیٹرنگ ہوسٹ کو ان سرورز سے الگ رکھیں جن کی یہ نگرانی کرتا ہے، PDPL اور NCA کی تعمیل کے لیے ڈیٹا کو مملکت کے اندر رکھیں، اور جیسے جیسے ٹریفک بڑھے حدود پر نظرِ ثانی کرتے رہیں۔

اپنی ایپس اور اپنے مانیٹرنگ اسٹیک کو ہوسٹ کرنے کے لیے کوئی قابلِ اعتماد، مملکت کے اندر VPS چاہیے — مقامی عربی سپورٹ اور شفاف قیمتوں کے ساتھ؟ اپنا Skyline Cloud اکاؤنٹ بنائیں اور منٹوں میں تعینات کریں۔