सर्वर अपटाइम की निगरानी कैसे करें और अलर्ट कैसे सेट करें

बाहर से सर्वर अपटाइम की निगरानी करने, अंदर से सेहत पर नज़र रखने, और कुछ बिगड़ने पर कुछ ही सेकंड में अलर्ट पाने के लिए एक व्यावहारिक, चरण-दर-चरण मार्गदर्शिका — Skyline Cloud VPS पर मुफ़्त, ओपन टूल्स का उपयोग करते हुए।

"अपटाइम मॉनिटरिंग" का असल मतलब क्या है

अपटाइम मॉनिटरिंग दो अलग-अलग सवालों का जवाब देती है, और एक भरोसेमंद सेवा चलाने के लिए आपको दोनों की ज़रूरत होती है:

• क्या मेरा सर्वर बाहर से पहुँच योग्य है? (बाहरी/ब्लैक-बॉक्स मॉनिटरिंग) — क्या इंटरनेट पर एक असली क्लाइंट को स्वस्थ प्रतिक्रिया मिलती है?
• क्या मेरा सर्वर अंदर से स्वस्थ है? (आंतरिक/व्हाइट-बॉक्स मॉनिटरिंग) — CPU, मेमोरी, डिस्क, और Nginx, MySQL या आपकी ऐप प्रक्रिया जैसी व्यक्तिगत सेवाएँ।

बाहरी जाँचें उन आउटेज को पकड़ती हैं जिन्हें आपके उपयोगकर्ता देखते हैं। आंतरिक जाँचें कारणों को पकड़ती हैं — एक भरती हुई डिस्क, एक बेकाबू प्रक्रिया, स्वैप थ्रैशिंग — अक्सर इससे पहले कि वे आउटेज में बदल जाएँ। यह गाइड एक Linux 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 जैसे सेल्फ-होस्टेड चेकर का उपयोग करें। सेल्फ-होस्टिंग आपके मॉनिटरिंग डेटा को Kingdom के भीतर रखती है — जो 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 टाइमर द्वारा चलाई गई एक छोटी स्क्रिप्ट ज़रूरी बातों को कवर कर लेती है। /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 टाइमर और node_exporter के माध्यम से आंतरिक सेहत निगरानी, और मल्टी-चैनल अलर्टिंग है जिसे आपने वास्तव में सत्यापित किया है। अपने मॉनिटरिंग होस्ट को उन सर्वरों से अलग रखें जिन्हें यह देखता है, डेटा को PDPL और NCA अनुपालन के लिए Kingdom के भीतर रखें, और जैसे-जैसे ट्रैफ़िक बढ़े, थ्रेशोल्ड पर दोबारा नज़र डालें।

क्या आपको अपने ऐप्स और अपने मॉनिटरिंग स्टैक को होस्ट करने के लिए एक भरोसेमंद, इन-Kingdom VPS चाहिए — स्थानीय अरबी समर्थन और पारदर्शी मूल्य निर्धारण के साथ? अपना Skyline Cloud खाता बनाएँ और कुछ ही मिनटों में डिप्लॉय करें।