यह Uptime Kuma से कैसे अलग है?

Uptime Kuma बताता है “क्या यह चालू है?”। Prometheus और Grafana बताते हैं “यह धीमा क्यों है, और कब से?”: समय के साथ CPU, मेमोरी, डिस्क, नेटवर्क और ऐप्लिकेशन के मेट्रिक्स। बहुत से लोग दोनों चलाते हैं: आउटेज अलर्ट के लिए Kuma, रुझानों और क्षमता योजना के लिए Grafana।

Prometheus कितनी डिस्क इस्तेमाल करता है?

कंप्रेशन के बाद लगभग 1–2 बाइट प्रति सैंपल। दस सर्वर, हर एक हज़ार सीरीज़ एक्सपोर्ट करता हुआ, हर 15 सेकंड में स्क्रेप, यानी रोज़ लगभग 6 करोड़ सैंपल: करीब 100 MB। डिफ़ॉल्ट 15 दिन की अवधि के साथ यह कुछ गीगाबाइट होता है।

क्या NAT प्लान वाले सर्वर मॉनिटर कर सकते हैं?

हाँ, लेकिन स्क्रेप करके नहीं: NAT सर्वर अपने exporter पर आने वाले कनेक्शन स्वीकार नहीं करता। NAT मशीन पर Prometheus को agent मोड में चलाएँ और remote_write से मेट्रिक्स अपने मॉनिटरिंग सर्वर पर भेजें। मॉनिटरिंग सर्वर खुद डेडिकेटेड IP वाले प्लान पर होना चाहिए।

मॉनिटरिंग सर्वर किस प्लान पर हो?

Micro-IP (2 GB RAM, $10/माह) एक-दो दर्जन होस्ट आराम से संभाल लेता है। अगर आप उच्च कार्डिनैलिटी वाले ऐप्लिकेशन मेट्रिक्स जोड़ते हैं या कई महीनों का डेटा रखते हैं, तो Small-IP पर जाएँ। डेडिकेटेड IP से Grafana को HTTPS मिलता है और एक स्थिर पता भी, जिसे आप अपने लक्ष्य सर्वरों पर अनुमति सूची में डाल सकते हैं।

क्या मॉनिटरिंग सर्वर उन सर्वरों से अलग होना चाहिए जिन्हें वह मॉनिटर करता है?

हाँ। अगर Grafana उसी सर्वर पर चल रहा है जिसकी मेमोरी अभी-अभी ख़त्म हुई है, तो ठीक उसी समय आपकी नज़र समस्या से हट जाती है जब उसकी सबसे ज़्यादा ज़रूरत है। एक छोटा अलग VPS तब भी चलता रहता है जब प्रोडक्शन मशीन गिर जाती है।

Grafana + Prometheus से सर्वर मॉनिटरिंग के लिए VPS

अपने सभी सर्वरों के CPU, RAM, डिस्क और सेवाओं के मेट्रिक्स एक जगह इकट्ठा करें: एक VPS पर, HTTPS के पीछे Prometheus, node_exporter और Grafana।

“सर्वर धीमा है” एक बेकार बग रिपोर्ट है, जब तक आप ग्राफ़ खोलकर यह न देख सकें कि क्रैश से पहले तीन दिन तक मेमोरी लगातार बढ़ती रही। Prometheus और Grafana आपको यही देते हैं: हर सर्वर का CPU, RAM, डिस्क और नेटवर्क, हर 15 सेकंड में दर्ज, और ऐसे ग्राफ़ में बना जिन्हें आप पीछे तक स्क्रॉल कर सकें। इन्हें उनके अपने छोटे VPS पर रखें, तो प्रोडक्शन मशीन गिरने पर भी ये निगरानी करते रहेंगे।

हिस्से

node_exporter: जिस भी सर्वर पर नज़र रखनी है उस पर चलता है, और पोर्ट 9100 पर सिस्टम मेट्रिक्स उपलब्ध कराता है।
Prometheus: मॉनिटरिंग VPS पर इन मेट्रिक्स को खींचता (scrape) और सहेजता है।
Grafana: HTTPS के पीछे डैशबोर्ड।
वैकल्पिक रूप से Alertmanager या Grafana अलर्टिंग, जो किसी सीमा के पार होने पर आपको संदेश भेजे।

आपको क्या चाहिए

Micro-IP ($10/माह, 2 vCPU, 2 GB RAM, 25 GB) एक-दो दर्जन सर्वरों पर नज़र रखता है। ज़्यादा होस्ट, कस्टम ऐप मेट्रिक्स या महीनों का डेटा रखना हो तो: Small-IP।
मॉनिटरिंग सर्वर के लिए एक डेडिकेटेड IPv4: Grafana HTTPS पर परोसा जाता है, और आपके लक्ष्य सर्वर पोर्ट 9100 के लिए सिर्फ़ एक स्थिर पते को अनुमति दे सकते हैं।

1. हर लक्ष्य सर्वर पर node_exporter

apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp

203.0.113.10 को अपने मॉनिटरिंग VPS के पते से बदलें। पोर्ट 9100 को कभी पूरी दुनिया के लिए खुला न छोड़ें: यह आपके सर्वर के बारे में बहुत कुछ उजागर करता है।

2. मॉनिटरिंग VPS पर Prometheus और Grafana

apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring

cat > prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: nodes
    static_configs:
      - targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF

cat > compose.yml <<'EOF'
services:
  prometheus:
    image: prom/prometheus
    volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
    command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
    ports: [ "127.0.0.1:9090:9090" ]
    restart: unless-stopped
  grafana:
    image: grafana/grafana
    volumes: [ "grafana:/var/lib/grafana" ]
    ports: [ "127.0.0.1:3000:3000" ]
    restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF

docker compose up -d

Grafana के आगे HTTPS:

echo 'grafana.example.com {
    reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy

लॉग इन करें (admin / admin, फिर पासवर्ड बदलें), http://prometheus:9090 पर Prometheus को डेटा स्रोत के रूप में जोड़ें, और समुदाय का “Node Exporter Full” डैशबोर्ड (ID 1860) इम्पोर्ट करें। लगभग एक मिनट में आपके पास पूरा सिस्टम डैशबोर्ड होगा।

NAT प्लान वाले सर्वर

NAT सर्वर सिर्फ़ अपने निजी SSH पोर्ट पर आने वाले कनेक्शन स्वीकार करता है, इसलिए Prometheus उसके exporter को स्क्रेप नहीं कर सकता। दिशा उलट दें: NAT मशीन पर Prometheus को agent मोड में चलाएँ और डेटा मॉनिटरिंग सर्वर पर भेजें, जो पहले से ही रिमोट राइट स्वीकार करता है (ऊपर वाला --web.enable-remote-write-receiver फ़्लैग)।

# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
  - job_name: self
    static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
  - url: https://prom-push.example.com/api/v1/write

पोर्ट 9090 को सीधे खोलने के बजाय, इस पुश एंडपॉइंट को Caddy के ज़रिए basic auth के साथ उपलब्ध कराएँ।

ईमानदार टिप्पणियाँ

Prometheus खींचने (pull) वाला तरीका अपनाता है: आपके नियंत्रण वाले सर्वरों के समूह के लिए बढ़िया, और NAT के पीछे की हर चीज़ के लिए असुविधाजनक, इसीलिए agent वाली तरकीब है। इसका लोकल स्टोरेज सालों के इतिहास के लिए नहीं बना; लंबे समय तक डेटा रखना हो तो बाद में रिमोट स्टोरेज जोड़ें। और डैशबोर्ड सिर्फ़ आधा फ़ायदा हैं: पहले ही दिन कम से कम तीन अलर्ट सेट करें (डिस्क 85% से ऊपर, मेमोरी पर दबाव, लक्ष्य बंद), वरना आप ग्राफ़ तभी देखेंगे जब कुछ पहले ही टूट चुका होगा।