Uptime Kuma Docker پر نگرانی کیسے چلائیں

آپ کیا بنا رہے ہیں

ایک چھوٹا کنٹینر جو باہر سے آپ کے دیگر سرورز اور ویب سائٹس پر نگرانی کرتا ہے۔ جیسے ہی کوئی جواب دینا بند کر دیتا ہے، یہ فوراً آپ کو بتاتا ہے۔ یہ اطلاع ای میل، Telegram، Discord یا webhook کے ذریعے آتی ہے۔ Uptime Kuma ایک Node پروسیس ہے جس کے پیچھے ایک SQLite فائل ہوتی ہے۔ اس لیے یہ 256-512 MB RAM میں باآسانی چلتا ہے۔ یہ آپ کو ایک لائیو ڈیش بورڈ، ہسٹری گراف اور عوامی اسٹیٹس پیج دیتا ہے۔ انسٹالیشن صرف دس سطروں کی Compose فائل ہے۔ جو حصہ واقعی اہمیت رکھتا ہے وہ یہ ہے کہ آپ اسے کہاں چلا رہے ہیں اور آپ کے الرٹس کبھی کسی ٹیسٹ میں فائر ہوئے ہیں یا نہیں۔ ایسا مانیٹر جس سے آپ نے کبھی یہ ثابت نہیں کیا کہ وہ آپ تک پہنچ سکتا ہے، اس سے بہتر ہے کہ وہ بالکل نہ ہو: یہ آپ کو یہ محسوس کراتا ہے کہ سب کور ہو گیا ہے، جبکہ وہ کچھ بھی نہیں دیکھ رہا ہوتا۔

نگرانی کو وہاں چلائیں جہاں بندیش تک نہیں پہنچ سکتی

یہ ایک فیصلہ پورے نظام کو کامیاب یا ناکام بنا دیتا ہے، اس لیے یہ سب سے پہلے ہے۔ Uptime Kuma کو اسی سرور پر نہ چلائیں جس کی وہ نگرانی کرتا ہے۔ اگر نگران آلہ اسی سرور پر موجود ہے جس کی وہ نگرانی کر رہا ہے، تو وہ واقعہ جس کی اہمیت آپ کو ہے، یعنی وہ سرور مر جانا یا اس کی میموری ختم ہو جانا، نگران آلے کو بھی مار دے گا اور آپ کو کوئی الرٹ نہیں ملے گا: ایک مردہ نگران آلے کی خاموشی کا مطلب "سب کچھ ٹھیک ہے" کے بالکل برابر ہے۔ سرور کے زندہ رہنے کے باوجود بھی ایک اور پھندا ہے: جو نگران آلہ localhost کی طرف اشارہ کرتا ہے وہ CPU کو ورک لوڈ کے ساتھ شیئر کرتا ہے، اس لیے لوڈ میں اچھال آنے پر اس کی اپنی چیک ٹائم آؤٹ ہو جاتی ہے اور ہدف کو down کر دیتی ہے، جو کہ ایک جھوٹا الرٹ ہے، جبکہ حقیقی صارفین کو خدمت مل رہی ہوتی ہے۔

اس لیے Uptime Kuma کو اسی VPS کے بجائے کسی دوسرے VPS پر چلائیں جس کی وہ نگرانی کرتا ہے، بالترتیب کسی مختلف فراہم کنندہ یا خطے میں، اور اپنی خدمات تک اسی طرح پہنچیں جیسے آپ کے صارفین پہنچتے ہیں: عوامی انٹرنیٹ پر، ہوسٹ نام کے ذریعے۔ ایک سستا انسٹنس کافی ہے، اور ایک چھوٹا نگرانی VPS آپ کے تمام سرورز کی نگرانی کر سکتا ہے۔ خود Kuma کے مر جانے کو پکڑنے کے لیے، کسی اور جگہ cron سے push heartbeat شامل کریں۔

ضروریات اور سائزنگ

• ایک نیا Ubuntu 24.04 VPS جس میں Docker Engine اور Compose v2 پلگ ان موجود ہو، جو Docker کے اپنے apt ریپوزٹری سے انسٹال ہوا ہو، نہ کہ docker.io ڈسٹرو پیکیج سے، کیونکہ وہ پیچھے رہ جاتا ہے۔
• 256 MB RAM چند مانیٹرز چلانے کے لیے کافی ہے؛ درجنوں مانیٹرز کے ساتھ ریورس پراکسی کے لیے 512 MB سے 1 GB آرام دہ ہے، اور چیکس کے درمیان CPU تقریباً بیکار رہتا ہے۔
• ایک ڈومین اور ایک DNS A ریکارڈ (مثلاً status.example.com جو VPS کی طرف اشارہ کرے)، صرف اس صورت میں اگر آپ TLS اور عوامی اسٹیٹس پیج چاہتے ہیں۔ نجی انسٹانس DNS کو چھوڑ سکتا ہے اور VPN یا SSH ٹنل استعمال کر سکتا ہے۔
• باہر کی طرف نیٹ ورک کنکٹیویٹی جہاں الارٹس جانے ہوں: اپنے میل فراہم کنندہ کے لیے SMTP، یا Telegram اور Discord کے لیے HTTPS۔

Compose فائل

اسے /srv/uptime-kuma/compose.yaml میں رکھیں۔

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

اسے اٹھائیں اور پہلی بوٹ کو دیکھیں:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

درست آغاز Listening on 3001 لاگ کرتا ہے اور پھر خاموش ہو جاتا ہے۔ اس فائل میں تین چیزیں جان بوجھ کر رکھی گئی ہیں۔

127.0.0.1:3001:3001، نہ کہ 3001:3001۔ Docker DNAT قواعد کے ساتھ پورٹس شائع کرتا ہے جن کی جانچ ufw کے پیکیٹ دیکھنے سے پہلے ہی ہو جاتی ہے، لہٰذا ایک نرا 3001:3001 آپ کے ڈیش بورڈ کو آپ کے فائر وال کی پرواہ کیے بغیر عوامی انٹرنیٹ پر لے جاتا ہے۔ لوپ بیک سے بائنڈ کرنا اسے نجی رکھتا ہے، جس میں صرف ریورس پراکسی بے نقاب ہوتی ہے؛ ایک نجی انسٹینس پراکسی کو چھوڑ سکتا ہے اور 3001 تک ایک سیلف ہوسٹڈ WireGuard VPN کے ذریعے پہنچ سکتا ہے۔

/app/data پر ایک نامزد والیوم۔ Uptime Kuma جو کچھ یاد رکھتا ہے، SQLite ڈیٹا بیس، آپ کے مانیٹرز، نوٹیفکیشن سیٹنگز اور اسٹیٹس پیج لوگو، وہ سب یہاں موجود ہے۔ اسے کھو دیں تو آپ ایک خالی ایڈمن اسکرین سے شروع کرتے ہیں؛ یہ وہ واحد چیز ہے جس کا آپ کو بیک اپ لینا چاہیے۔

امیج ایک بڑے ٹیگ، :2 پر پن ہے۔ یہ موجودہ مستحکم لائن ہے؛ اسے کاپی کرنے سے پہلے Docker Hub پر تازہ ترین بڑا ورژن چیک کریں، اور کبھی بھی latest جیسے متحرک ٹیگ کو ٹریک نہ کریں، جسے پروجیکٹ ڈیپریکیٹ کرتا ہے۔ اس امیج پر بڑے ورژن کا چھلانگ ایک یکطرفہ ڈیٹا بیس مائگریشن ہے جسے آپ جان بوجھ کر ٹرگر کرنا چاہتے ہیں، نہ کہ معمول کے پل پر اتفاق سے اس میں گھس جانا۔

ایک احتیاط: /app/data POSIX فائل لاکس والی فائل سسٹم پر ہونا چاہیے۔ ایک مقامی Docker والیوم ٹھیک ہے؛ NFS پر SQLite ڈیٹا بیس خراب ہو جاتا ہے اور آپ کو SQLITE_BUSY اور database disk image is malformed ملتے ہیں، لہٰذا کبھی بھی نیٹ ورک شیئر استعمال نہ کریں۔

پہلی چلان: منتظم اکاؤنٹ بنائیں

اپنے پراکسی کے ذریعے انسٹنس کو https://status.example.com پر کھولیں، یا SSH سرنگ کے ذریعے: ssh -L 3001:127.0.0.1:3001 user@your-vps چلائیں اور http://localhost:3001 کھولیں۔ پہلا صفحہ منتظم صارف نام اور پاس ورڈ کے لیے سیٹ اپ فارم ہے؛ کوئی طے شدہ لاگ ان موجود نہیں۔ حقیقی پاس ورڈ منتخب کریں: یہ ڈیش بورڈ آپ کی نگرانی کی جانے والی ہر چیز کے اندرونی پتے اور ٹوکن دیکھتا ہے۔ بعد میں بھول گئے؟ میزبان سے ری سیٹ کریں، براؤزر سے نہیں:

sudo docker compose exec uptime-kuma npm run reset-password

پہلے اپنے اطلاع چینلز شامل کریں، اور انہیں آزمائیں

مانیٹرز شامل کرنے سے پہلے الرٹس مرتب کریں، تاکہ ہر ایک بناتے وقت آپ ایک چینل منسلک کر سکیں۔ Settings پھر Notifications پھر Setup Notification پر جائیں، اور ہر چینل کے Test بٹن سے تصدیق کریں کہ پیغام پہنچتا ہے، کیونکہ بغیر آزمائے گئی اطلاع سیٹ اپ کی خاموشی سے ناکامی کا دوسرا سب سے عام ذریعہ ہے۔

ای میل (SMTP)۔ ہوسٹ، پورٹ، خفیہ نگاری، صارف نام، پاس ورڈ، ایک From اور ایک To درج کریں۔ دو کام کرنے والے امتزاج یہ ہیں: 465 جس میں "Secure" کو TLS/SSL پر سیٹ کیا گیا ہے، یا 587 جس میں STARTTLS ہے۔ Gmail اور دو فیکٹر تصدیق والے بیشتر فراہم کنندگان کے لیے آپ کو ایک ایپ پاس ورڈ بنانا ہوگا؛ عام اکاؤنٹ پاس ورڈ Error: Invalid login: 535-5.7.8 Username and Password not accepted واپس کرتا ہے۔

ٹیلیگرام۔ @BotFather کو پیغام بھیجیں، /newbot بھیجیں، بوٹ ٹوکن کاپی کریں۔ اپنی چیٹ آئی ڈی کے لیے، نئے بوٹ کو ایک بار پیغام بھیجیں، https://api.telegram.org/bot<token>/getUpdates کھولیں، اور JSON سے chat.id پڑھیں۔ وہ بوٹ جسے آپ نے پہلے پیغام نہیں بھیجا اس کا getUpdates خالی ہوتا ہے اور بھیجنے کے لیے کوئی جگہ نہیں ہوتی۔

ڈسکارڈ۔ چینل میں، Edit Channel پھر Integrations پھر Webhooks پھر New Webhook کھولیں، URL کاپی کریں، اور اسے Discord اطلاع کے طور پر پیسٹ کریں۔

عام ویب ہوک۔ کسی اور چیز کے لیے، جیسے Slack انکمنگ ویب ہوک، ایک حسب ضرورت اینڈ پوائنٹ، یا ہوم آٹومیشن ہوک، Webhook قسم آپ کی فراہم کردہ URL پر ایک JSON پے لوڈ POST کرتا ہے، اور شامل کردہ Apprise انٹیگریشن فہرست کے تقریباً نوے دیگر خدمات کا احاطہ کرتا ہے۔

نگرانیں شامل کریں، ایک وقت میں ایک قسم

Add New Monitor پر کلک کریں، ایک قسم منتخب کریں، اور Friendly Name، Check Interval (60 سیکنڈ مناسب ہے)، Retries ("down" قرار دینے سے پہلے مسلسل ناکامیاں؛ 2 یا 3 تاکہ ایک کھویا ہوا پیکیج پیج نہ بن جائے)، اور بھیجنے والی اطلاعات طے کریں۔ آپ جو اقسام استعمال کریں گے:

• HTTP(s). ایک مکمل URL۔ Up کا مطلب ایک قابل قبول اسٹیٹس کوڈ ہے (بنیادی طور پر 200-299؛ اگر 301 یا 401 آپ کے لیے عام ہے تو اسے Accepted Status Codes کے تحت وسیع کریں)۔ یہ ویب سائٹس اور APIs کے لیے آپ کا بنیادی ذریعہ ہے۔
• HTTP(s) - Keyword. وہی درخواست، لیکن "up" کے لیے باڈی میں ایک اسٹرنگ کی موجودگی بھی ضروری ہے، یا Invert کی عدم موجودگی۔ یہ اس صورتحال کو پکڑتا ہے جب سائٹ 200 OK واپس کرتے ہوئے "Error establishing a database connection" رینڈر کرتی ہے، جسے ایک عام HTTP چیک صحت مند سمجھتا ہے۔
• TCP Port. میزبان اور پورٹ پر ایک سادہ TCP کنکشن، ان چیزوں کے لیے جو HTTP نہیں ہیں: 22 پر SSH، 5432 پر Postgres، 25 پر SMTP سرور، یا گیم سرور۔
• Ping. ICMP echo: سستی قابل رسائی اور لیٹنسی۔ لیکن بہت سے نیٹ ورکس اور کلاؤڈ فائر والز ICMP کو ڈراپ کرتے ہیں، اس لیے ایک سرخ ping مانیٹر کا مطلب "host down" یا "provider blocks ping" ہو سکتا ہے؛ ایک TCP مانیٹر کے ساتھ تصدیق کریں۔
• DNS. آپ کے بتائے ہوئے ریزولور کے خلاف ایک ریکارڈ (A, AAAA, MX, TXT وغیرہ) کو حل کرتا ہے، اور جواب کی تصدیق کر سکتا ہے، جس سے رجسٹرار یا DNS بندش جلدی پکڑی جاتی ہے۔
• Push. الٹا مانیٹر، جس کا ذکر اگلے حصے میں ہے۔

ایک cron job کی نگرانی push (heartbeat) monitor کے ساتھ

اوپر دیے گئے ہر monitor کا کام بیرونی طور پر آپ کی سروس تک رسائی حاصل کرنا ہے۔ ایک push monitor اس کے برعکس کام کرتا ہے: Uptime Kuma انتظار کرتا ہے، اور آپ کا job اسے بتانے کے لیے کال کرتا ہے کہ "میں چل گیا۔" یہ کسی بیک اپ یا cron کی نگرانی کا واحد قابل اعتماد طریقہ ہے: ایک HTTP check صرف اتنا جانتا ہے کہ ایک URL جواب دے رہا ہے، لیکن صرف job خود جانتا ہے کہ اس نے کام مکمل کیا ہے۔

Push قسم کا ایک monitor بنائیں۔ Uptime Kuma ایک منفرد URL بناتا ہے جیسے:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Heartbeat Interval کو اس وقت کے مطابق سیٹ کریں جتنی بار job چلتا ہے، اس میں تھوڑا اضافی وقت بھی شامل کریں۔ پھر اسکرپٹ کے آخر میں ایک لائن شامل کریں، تاکہ یہ صرف کامیابی پر فائر ہو:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

اگر job ناکام ہو جاتا ہے، تو set -e curl سے پہلے ہی رک جاتا ہے؛ اگر سرور ڈاؤن ہے، تو یہ کبھی نہیں چلے گا۔ دونوں صورتوں میں heartbeat رک جاتی ہے، اور ایک بار جب interval-plus-retries کا وقت گزر جاتا ہے، Uptime Kuma monitor کو down پر تبدیل کر دیتا ہے اور آپ کو الرٹ بھیجتا ہے۔ اس push token کو راز سمجھیں: جس کے پاس بھی یہ ہوگا وہ ایک درست heartbeat جعلسازی کر سکتا ہے۔

عوامی اسٹیٹس پیج بنائیں

اسٹیٹس پیج گاہک کا منظر ہے: کون سی سروسز چل رہی ہیں اور ان کی حالیہ تاریخ، بغیر آپ کے ڈیش بورڈ کو ظاہر کیے۔ Status Pages پھر New Status Page پر جائیں، اسے ایک نام اور slug دیں (عوامی پاتھ، جیسے /status/main)، مطلوبہ monitors کو "Websites" اور "APIs" جیسے گروپوں میں کھینچ کر شامل کریں، ایک لوگو اور مختصر تفصیل شامل کریں، پھر Save کریں۔ آپ پیج کو اپنے ڈومین سے بھی باندھ سکتے ہیں تاکہ status.example.com اسے براہ راست پیش کرے۔

دو احتیاطی تدابیر: صرف وہ monitors شامل کریں جنہیں آپ عوامی بنانے پر راضی ہیں، کیونکہ اسٹیٹس پیج ظاہر کرتا ہے کہ کوئی سروس موجود ہے اور وہ چل رہی ہے یا نہیں؛ اور ڈیش بورڈ آپ کے لاگ ان کے پیچھے محفوظ رہتا ہے جبکہ اسٹیٹس پیج جان بوجھ کر عوامی ہوتا ہے اور اسے auth کی ضرورت نہیں۔

اسے TLS کے ساتھ ریورس پراکسی کے پیچھے رکھیں، اور ویب ساکٹس کا خیال رکھیں

عوامی انسٹنس کے لیے، لوپ بیک باؤنڈ کنٹینر کے سامنے TLS اور ہوسٹ نام کے لیے ایک ریورس پراکسی لگائیں۔ جو بات سب کو الجھاتی ہے وہ یہ ہے: Uptime Kuma کا UI ایک لائیو Socket.IO ایپ ہے، اس لیے پراکسی کو WebSocket کنکشن کو اپ گریڈ کرنا چاہیے۔ یہ چھوڑ دیں تو پیج لوڈ تو ہو جاتا ہے لیکن کبھی کنیکٹ نہیں ہوتا؛ ڈیش بورڈ "Connecting..." پر ہی رہتا ہے، لائیو ہارٹ بیٹس کبھی اپڈیٹ نہیں ہوتے، اور براؤزر کنسول میں WebSocket connection to 'wss://.../socket.io/...' failed نظر آتا ہے۔

nginx اور certbot انسٹال کریں، پھر وہ vhost لکھیں جو لوپ بیک پورٹ پر پراکسی کرتا ہے۔ ابھی اسے پورٹ 80 پر رکھیں اور certbot کو بعد میں TLS شامل کرنے دیں؛ چیلنج، تجدید ٹائمر اور اس کے فیلر موڈز کی تفصیل certbot اور nginx کے ساتھ Let's Encrypt سرٹیفکیٹس جاری کرنا میں دی گئی ہے۔

sudo apt install -y nginx certbot python3-certbot-nginx

اسے /etc/nginx/sites-available/status.example.com کے نام سے محفوظ کریں؛ یہ دو WebSocket لائنیں ہیں اہم ہیں:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

سائٹ کو فعال کریں، کنفیگریشن ٹیسٹ کریں، پھر certbot کو بلاک کو 443 پر لسن کرنے، سرٹیفکیٹ ڈالنے اور HTTP-to-HTTPS ریڈائریکٹ شامل کرنے کے لیے دوبارہ لکھنے دیں:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Upgrade اور Connection "upgrade" کا جوڑا ہی سب کچھ ہے، اور proxy_read_timeout 3600s nginx کو لانگ لائیو ساکٹ کو ختم ہونے سے روکتا ہے؛ certbot دونوں کو اپنی بنائی ہوئی 443 بلاک میں کاپی کر لیتا ہے۔ اگر آپ پہلے ہی ایک پراکسی کے پیچھے کئی کنٹینر چلا رہے ہیں، تو Traefik کے ساتھ آٹومیٹک TLS کے ذریعے انہیں روٹ کرنا کنٹینر لیبلز کے ساتھ یہی کام کرتا ہے اور ڈیفالٹ طور پر WebSocket اپ گریڈز کو فارورڈ کرتا ہے۔

پورے vhost پر basic-auth نہ لگائیں، کیونکہ اس سے عوامی اسٹیٹس پیج اور /api/push اینڈپوائنٹ بھی بلاک ہو جاتے ہیں۔ Uptime Kuma کا بلٹ ان لاگن برقرار رکھیں، اگر یہ انٹرنیٹ سے قابل رسائی ہے تو بار بار فیلڈ ہونے والے لاگ ان کی نگرانی کے لیے fail2ban شامل کریں، اور اگر ڈیش بورڈ کو عوامی ہونے کی ضرورت نہیں، تو پراکسی ہٹا دیں اور اسے VPN کے ذریعے استعمال کریں۔

سرٹیفکیٹ ختم ہونے کی نگرانی، درست طریقہ

ایک HTTP(s) مانیٹر TLS سرٹیفکیٹ کے ختم ہونے سے پہلے بھی آپ کو تنبیہ کر سکتا ہے: Certificate Expiry Notification کو منتخب کریں اور Uptime Kuma مقررہ دنوں قبل خبردار کر دیتا ہے۔ دو غلطیاں اسے غلط پڑنے کا سبب بنتی ہیں۔ hostname کے ذریعے نگرانی کریں، IP نہیں، ورنہ SNI کے بغیر درخواست پر سرور کا ڈیفالٹ سرٹیفکیٹ ملے گا اور آپ کو Hostname/IP does not match certificate's altnames نظر آئے گا۔ اور اس مانیٹر پر Ignore TLS/SSL Error کو منتخب نہ کریں جس سے آپ ختم ہونے کی تنبیہ چاہتے ہیں: یہ ٹوگل self-signed اندرونی ہوسٹس (unable to verify the first certificate، DEPTH_ZERO_SELF_SIGNED_CERT) کے لیے ہے، لیکن یہ Uptime Kuma کو سرٹیفکیٹ چیک کرنے سے مکمل روک دیتا ہے، ختم ہونے کی جانچ بھی شامل ہے۔

بیک اپ: یہ ایک ڈائریکٹری ہے

چونکہ سب کچھ /app/data میں موجود ہوتا ہے، بیک اپ اس ولیوم کی ایک کاپی ہے جو کنٹینر بند ہونے کی حالت میں لی جاتی ہے، تاکہ SQLite فائل مستحکم رہے:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

پہلے docker volume ls | grep kuma سے ولیوم کا اصل نام تصدیق کریں، کیونکہ Compose اس کے ساتھ پروجیکٹ ڈائریکٹری کا سابقہ لگاتا ہے۔ پھر tarball کو باکس سے باہر کاپی کریں، کیونکہ اسی VPS پر موجود بیک اپ محض ایک کاپی ہے، بیک اپ نہیں۔ بحالی اس کا الٹا ہے: اسٹیک کو روکیں، خالی /app/data ولیوم میں استخراج کریں، اور اسے شروع کریں۔

اپ گریڈز

اپ گریڈ دراصل ایک امیج پل ہے:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

نیا کنٹینر پہلی اسٹارٹ پر کوئی بھی ڈیٹا بیس مائیگریشن چلاتا ہے؛ docker compose logs -f کو دیکھیں۔ پل کرنے سے پہلے اوپر دیا گیا بیک اپ لیں، اور ایک بڑے ٹیگ کے اندر ہی رہیں: :1 سے :2 پر جانا ایک یکطرفہ مائیگریشن ہے، اس لیے پہلے بیک اپ لیں اور ریلیز نوٹس چیک کریں۔

ناکامی کے طریقے، جن سے آپ جن اسٹرنگز کا سامنا کریں گے

localhost کی طرف اشارہ کرنے والے مانیٹر پر غلط "down"۔ مانیٹر timeout of 48000ms exceeded یا connect ETIMEDOUT کے ساتھ سرخ ہو جاتا ہے، حالانکہ سروس آپ کے لیپ ٹاپ سے جواب دیتی ہے۔ اگر یہ اسی ہوسٹ کی طرف اشارہ کرتا ہے جس پر Uptime Kuma چل رہا ہے، تو CPU یا میموری کا اچھالاؤ چیک کو بھوکا مار دیتا ہے، نہ کہ ہدف کو۔ مانیٹر کو ایک الگ VPS پر منتقل کریں اور پبلک ہوسٹ نام کو ہدف بنائیں۔

connect ECONNREFUSED 127.0.0.1:443 (یا کوئی بھی پورٹ)۔ اس پورٹ پر کچن نہیں سن رہا تھا: یا تو سروس ڈاؤن ہے، یا آپ نے کنٹینر کے اندر سے localhost کی نگرانی کی، جہاں 127.0.0.1 کنٹینر ہے، آپ کا سرور نہیں۔ پبلک ہوسٹ نام کی نگرانی کریں، لوپ بیک کی نہیں۔

ای میل ٹیسٹ پر Invalid login: 535-5.7.8 Username and Password not accepted۔ SMTP اسناد غلط ہیں، یا فراہم کنندہ ایک ایپ مخصوص پاس ورڈ چاہتا ہے اور اسے آپ کا اکاؤنٹ پاس ورڈ ملا ہے۔ ایک ایپ پاس ورڈ بنائیں اور اسے پیسٹ کریں۔

ای میل ٹیسٹ پر connect ETIMEDOUT یا queryA ETIMEDOUT <host>۔ غلط پورٹ، یا فراہم کنندہ آؤٹ باؤنڈ SMTP کو بلاک کرتا ہے۔ تصدیق کریں کہ 465 یا 587 Secure/STARTTLS سیٹنگ سے میل کھاتا ہے، اور ہوسٹ سے nc -vz smtp.example.com 587 کے ساتھ ٹیسٹ کریں۔ بہت سے فراہم کنندگان آؤٹ باؤنڈ 25 کو بلاک کرتے ہیں اور کچھ جمع کرنے والے پورٹس کو تب تک بلاک کرتے ہیں جب تک آپ درخواست نہ کریں۔

ای میل ٹیسٹ پر self signed certificate یا unable to verify the first certificate۔ آپ کا SMTP سرور ایک سرٹیفکیٹ پیش کرتا ہے جس پر Node اعتبار نہیں کرے گا؛ میل سرور کے سرٹیفکیٹ کو ٹھیک کریں بجائے اسے چھپانے کے۔

ڈیش بورڈ "Connecting..." پر پھنسا ہوا ہے، کنسول WebSocket connection ... failed دکھاتا ہے۔ ریورس پراکسی WebSocket کو اپ گریڈ نہیں کر رہی۔ nginx پر Upgrade اور Connection "upgrade" ہیڈرز شامل کریں، یا ایسا پراکسی استعمال کریں جو انہیں بطور ڈیفالٹ فارورڈ کرتا ہے جیسے Traefik یا Caddy۔ HTML لوڈ ہوتا ہے کیونکہ وہ ایک عام HTTP GET ہے؛ صرف لائیو ساکٹ کو اپ گریڈ کی ضرورت ہے۔

سرٹیفکیٹ ختم ہونے کا مانیٹر کبھی متنبہ نہیں کرتا، یا غلط متنبہ کرتا ہے۔ یا تو Ignore TLS/SSL Error ٹک ہے، جو سرٹیفکیٹ چیکنگ کو غیر فعال کر دیتا ہے، یا مانیٹر ایک IP کی طرف اشارہ کرتا ہے اور غائب SNI کی وجہ سے غلط سرٹیفکیٹ پڑھتا ہے، جس سے Hostname/IP does not match certificate's altnames نظر آتا ہے۔ انگور کو ہٹائیں، ہوسٹ نام سے نگرانی کریں۔

لاگز میں SQLITE_BUSY یا database disk image is malformed۔ /app/data والیوم ایک ایسی فائل سسٹم پر ہے جس میں مناسب فائل لاکنگ نہیں ہے، عام طور پر NFS؛ اسے ایک مقامی Docker والیوم پر منتقل کریں اور بیک اپ سے بحال کریں۔

FAQ

اپ ٹائم مانیٹر کہاں چلائیں؟

ان سرورز سے الگ ایک سرور پر جن کی نگرانی کرتا ہے، بالترتیب کسی اور فراہم کنندہ یا خطے میں۔ وہ تک عوامی انٹرنیٹ پر ہوسٹ نام کے ذریعے پہنچے، بالکل جیسے آپ کے صارفین کرتے ہیں۔ اگر مانیٹر اپنے اہداف کے ساتھ ایک ہی باکس پر ہو، تو وہ بندش جو سرور کو مار دیتی ہے وہ مانیٹر کو بھی مار دیتی ہے، اور ایک زیادہ بوجھ والا ہوسٹ اسے ان سروسز کے بارے میں "ڈاؤن" چلانے پر مجبور کرتا ہے جو درست ہیں۔ ایک چھوٹا الگ VPS دونوں سے بچاتا ہے۔

ٹیلیگرام یا ای میل پر الرٹس کیسے حاصل کروں؟

Settings then Notifications کے تحت چینل شامل کریں، پھر اسے ہر مانیٹر سے منسلک کریں۔ ٹیلیگرام کے لیے، @BotFather کے ساتھ ایک بوٹ بنائیں اور https://api.telegram.org/bot<token>/getUpdates سے chat.id پڑھیں؛ ای میل کے لیے، SSL کے لیے 465 یا STARTTLS کے لیے 587 استعمال کریں، ایک ایپ پاس ورڈ کے ساتھ اگر آپ کا فراہم کنندہ دو عنصرانہ تصدیق استعمال کرتا ہے۔ Test دبائیں اور تصدیق کریں کہ پیغام پہنچتا ہے اس پر انحصار کرنے سے پہلے۔

کیا Uptime Kuma ایک کرون جاب یا بیک اپ اسکرپٹ کی نگرانی کر سکتا ہے؟

ہاں، وہ Push مانیٹر ہے: Uptime Kuma آپ کو ایک URL دیتا ہے اور آپ اسکرپٹ کے آخر میں curl کرتے ہیں تاکہ وہ صرف کامیابی پر فائر ہو۔ اگر جاب ناکام ہو یا باکس ڈاؤن ہو تو ہارٹ بیٹ کبھی نہیں پہنچتی، اور وقفہ گزرنے کے بعد آپ کو الرٹ بھیجا جاتا ہے۔ یہ جاننے کا واحد قابل اعتماد طریقہ ہے کہ ایک شیڈولڈ جاب واقعی چلی، چونکہ ایک بیرونی چیک اس کے اندر نہیں دیکھ سکتا۔

Uptime Kuma بمقابلہ Zabbix، میں کون سا چلاؤں؟

Uptime Kuma دس منٹ میں تقریباً کوئی وسائل کے بغیر "کیا یہ اوپر ہے، باہر سے، اور کیا اس نے مجھے الرٹ کیا" کا جواب دیتا ہے، اس کے ساتھ ایک اسٹیٹس پیج۔ یہ CPU، میموری اور ڈسک رجحانات یا بیڑے کی سطح کی حدود جیسے گہرے میٹرکس جمع نہیں کرتا؛ اس کے لیے، ایک مکمل Zabbix مانیٹرنگ سرور زیادہ بھاری، ایجنٹ پر مبنی ٹول ہے، اور بہت سے لوگ دونوں چلاتے ہیں۔ ابھی بھی فیصلہ کر رہے ہیں کہ کیا چلائیں؟ 2026 میں کیا سیلف ہوسٹ کرنا ہے کا ہمارا مرتبہ مانیٹرنگ کو سیاق میں رکھتا ہے۔