Kubernetes मॉनिटरिंग: Prometheus, Grafana, अलर्ट

संक्षिप्त उत्तर: एक SME के Kubernetes क्लस्टर पर उपयोगी मॉनिटरिंग तीन फ़ैसलों में सिमट जाती है, तीन सौ डैशबोर्ड में नहीं। kube-prometheus-stack इंस्टॉल करें (वह कम्युनिटी चार्ट जिसमें Prometheus, Alertmanager, Grafana और kubernetes-mixin के नियम साथ आते हैं), रिटेंशन को 50 Gi वॉल्यूम पर 15 दिन रखें — यानी OVHcloud या Scaleway पर ब्लॉक स्टोरेज के लगभग 2 से 5 € प्रति माह —, और फिर डिफ़ॉल्ट रूप से आने वाले 80 % अलर्ट नियम हटा दें, सिर्फ़ वे दस-बारह रखें जो किसी उपयोगकर्ता को वास्तव में महसूस होने वाले लक्षण का वर्णन करते हैं। जो अलर्ट कोई कार्रवाई शुरू न करे, वह सावधानी नहीं, कॉन्फ़िगरेशन की गड़बड़ी है।

हम नियमित रूप से ऐसे क्लस्टर संभालते हैं जहाँ Prometheus एक साल से चल रहा है। पैटर्न हमेशा एक ही होता है: एक #alerts Slack चैनल जो आठ महीने से खामोश है क्योंकि नोटिफ़िकेशन अब कोई बर्दाश्त नहीं करता, एक Grafana जिसमें चालीस डैशबोर्ड हैं और उनमें से तीन कभी एक बार खुले, और 10 दिन की रिटेंशन एक ऐसी डिस्क पर जो हर पंद्रह दिन में भर जाती है। इस बीच असली घटना — कनेक्शनों से भरा एक PostgreSQL डेटाबेस, हर रात 2 बजे OOM killer द्वारा मारा जाने वाला एक pod — किसी की नज़र में नहीं आती। यह लेख उस इंस्टॉलेशन का वर्णन करता है जो हम डिफ़ॉल्ट रूप से लगाते हैं और, सबसे ज़रूरी, अलर्ट की छँटाई का।

टूल चुनने से पहले यह तय करें कि आप क्या मापना चाहते हैं

ज़रूरत को टुकड़ों में बाँटें। एक SME की वेबसाइटों और ऐप्लिकेशनों को चलाने वाले क्लस्टर पर मॉनिटरिंग चार अलग-अलग सवालों के जवाब देती है, और उनके लिए एक ही टूल नहीं चलता।

सबसे महँगी गलतफ़हमी यह है कि सब कुछ Prometheus से करवाने की कोशिश की जाए। Prometheus कम कार्डिनैलिटी वाला टाइम-सीरीज़ डेटाबेस है: यह एग्रीगेट किए गए संख्यात्मक मेट्रिक्स स्टोर करता है, अलग-अलग इवेंट नहीं। किसी लेबल में रिक्वेस्ट आईडी या उपयोगकर्ता का ई-मेल डालने से मेमोरी फट पड़ती है — नामकरण की बेहतर प्रथाओं पर Prometheus का दस्तावेज़ और इंस्ट्रूमेंटेशन वाला दस्तावेज़ यही दोहराते हैं: लेबलों का हर संयोजन एक अलग सीरीज़ बनाता है।

3 से 10 नोड के दायरे वाले SME क्लस्टर के लिए हमारी सिफ़ारिश:

• मेट्रिक्स: kube-prometheus-stack, क्लस्टर के भीतर सेल्फ़-होस्टेड। छोटी रिटेंशन, स्पष्ट एग्रीगेशन।
• लॉग: एक ऑब्जेक्ट बकेट के साथ Loki, या प्रदाता की लॉग सेवा अगर क्लस्टर मैनेज्ड है। लॉग भारी होते हैं और कम ही देखे जाते हैं: 0.01 € प्रति GB-माह वाला ऑब्जेक्ट स्टोरेज इन्हें बेदर्द बना देता है।
• ट्रेस: सिर्फ़ तब जोड़ें जब किसी ऐप्लिकेशन में दो से अधिक सेवाएँ एक-दूसरे को कॉल करती हों। उससे पहले यह समय की बर्बादी है।

kube-prometheus-stack इंस्टॉल करें, वैल्यू में गलती किए बिना

kube-prometheus-stack चार्ट prometheus-community कम्युनिटी द्वारा मेंटेन किया जाता है। इसमें Prometheus Operator, Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics और kubernetes-mixin प्रोजेक्ट से आए नियमों का पूरा सेट शामिल है। एक कमांड में ऐसी मॉनिटरिंग मिल जाती है जो काम करती है — और बहुत ज़्यादा चिल्लाती है।

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  -f values.yaml

असली खेल values.yaml फ़ाइल में होता है। यह वह ढाँचा है जिसका हम उपयोग करते हैं, storageClassName को प्रदाता के अनुसार बदलते हुए (OVHcloud पर csi-cinder-high-speed, Scaleway पर scw-bssd):

prometheus:
  prometheusSpec:
    retention: 15d
    retentionSize: 40GiB
    scrapeInterval: 30s
    evaluationInterval: 30s
    resources:
      requests:
        cpu: 200m
        memory: 2Gi
      limits:
        memory: 4Gi
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: csi-cinder-high-speed
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
    # केवल स्पष्ट रूप से लेबल किए गए ServiceMonitor ही लें
    serviceMonitorSelectorNilUsesHelmValues: false

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: csi-cinder-high-speed
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 5Gi

grafana:
  adminPassword: ""        # बाहरी Secret से इंजेक्ट किया गया
  persistence:
    enabled: true
    size: 5Gi
  defaultDashboardsTimezone: Europe/Paris

तीन सेटिंग्स समझाने लायक हैं, क्योंकि हम जिन मॉनिटरिंग समस्याओं को ठीक करते हैं, उनमें से ज़्यादातर की वजह यही हैं।

retention और retentionSize, हमेशा साथ

अकेला retention: 15d डिस्क की सुरक्षा नहीं करता: अगर कार्डिनैलिटी बढ़ी (नई सेवा, नए लेबल), तो वॉल्यूम 15 दिन से पहले भर जाता है और Prometheus रुक जाता है। retentionSize एक कठोर सीमा तय करता है। इसे वॉल्यूम के आकार के लगभग 80 % पर सेट करें — 50 Gi के PVC के लिए 40 GiB — जिससे कॉम्पैक्शन के दौरान बन रहे ब्लॉकों के लिए जगह बची रहे।

आकार तय करने के लिए स्टोरेज पर Prometheus के दस्तावेज़ का अनुमानित नियम अब भी काम का है: जगह ≈ रिटेंशन अवधि × प्रति सेकंड नमूनों की संख्या × एक नमूने का औसत आकार (कंप्रेशन के बाद लगभग 1 से 2 बाइट)। हमारे 5-नोड क्लस्टरों पर, जहाँ तीस के आसपास सेवाएँ इंस्ट्रूमेंटेड हैं, व्यवहार में 15 दिन के लिए 15 से 25 Gi देखने को मिलता है। इसलिए 50 Gi का PVC ज़रूरी मार्जिन से दोगुना छोड़ता है, और लागत महीने के कुछ यूरो।

एक मेमोरी लिमिट, CPU लिमिट कभी नहीं

Prometheus की मेमोरी खपत सक्रिय सीरीज़ की संख्या के अनुपात में होती है, और कॉम्पैक्शन तथा डैशबोर्ड की भारी क्वेरी के दौरान उसमें उछाल आता है। limits.memory उसे पूरा नोड ले डूबने से रोकती है; इसके उलट limits.cpu उसे कॉम्पैक्शन के दौरान थ्रॉटल करवाती है और हर जगह झूठे अलर्ट पैदा करती है। यही तर्क ऐप्लिकेशनों पर भी लागू होता है, जैसा हमने HPA और KEDA के साथ Kubernetes पर Next.js के ऑटोस्केलिंग वाले लेख में बताया है।

scrapeInterval 30 सेकंड, 15 नहीं

अंतराल दोगुना करने से स्टोर किया गया वॉल्यूम और CPU भार आधा हो जाता है। SME की वेबसाइटों और ऐप्लिकेशनों के लिए, संतृप्ति को 15 के बजाय 30 सेकंड में पकड़ने से कुछ नहीं बदलता: अलर्ट में शोर रोकने के लिए किसी भी हाल में for: 5m होता है। डिफ़ॉल्ट 15 सेकंड सिर्फ़ तब जायज़ हैं जब आप सेकंड-स्तर के SLO बना रहे हों।

वे आठ अलर्ट जो नोटिफ़िकेशन के हक़दार हैं

चार्ट के साथ आने वाले kubernetes-mixin नियम-सेट में सौ से ज़्यादा अलर्ट हैं। इनमें से बहुत-से कंट्रोल प्लेन की आंतरिक स्थितियाँ बताते हैं — OVHcloud, Scaleway या EKS के मैनेज्ड क्लस्टर पर अनुपयोगी, जहाँ वह कंट्रोल प्लेन आपका नहीं है। इसलिए इंस्टॉलेशन के बाद पहला कदम यही है कि जो आपसे संबंधित नहीं, उसे बंद कर दें:

defaultRules:
  create: true
  rules:
    etcd: false
    kubeApiserverAvailability: false
    kubeApiserverBurnrate: false
    kubeApiserverSlos: false
    kubeControllerManager: false
    kubeSchedulerAlerting: false
    kubeProxy: false

इसके बाद एक सीधा सिद्धांत लागू करें, जो SRE Book के « Monitoring Distributed Systems » अध्याय में Google द्वारा दर्ज अलर्टिंग दर्शन से लिया गया है: केवल उपयोगकर्ता को दिखने वाले लक्षणों पर अलर्ट करें, या उन कारणों पर जो अनिवार्य रूप से लक्षण बन जाएँगे। बाकी सब डैशबोर्ड में जाता है, नोटिफ़िकेशन में नहीं।

SME क्लस्टर पर हम जो सूची रखते हैं, वह यहाँ है, हर एक के औचित्य के साथ।

इस आधार में हम हमेशा हर एक्सपोज़्ड सेवा के लिए एक ऐप्लिकेशन-स्तरीय अलर्ट जोड़ते हैं, जो अकेले बीस इन्फ़्रास्ट्रक्चर नियमों की जगह ले लेता है: ingress या Gateway द्वारा देखा गया HTTP 5xx एरर रेट। Gateway API-संगत कंट्रोलर द्वारा एक्सपोज़ किए गए मेट्रिक्स पर PrometheusRule ऐसा दिखता है:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-availability
  namespace: monitoring
  labels:
    release: monitoring
spec:
  groups:
    - name: app-availability
      rules:
        - alert: HighHttp5xxRate
          expr: |
            sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
            /
            sum(rate(http_requests_total[5m])) by (service)
            > 0.02
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "{{ $labels.service }} पर 2 % से अधिक 5xx त्रुटियाँ"
            runbook: "https://wiki.interne/runbooks/http-5xx"

दो बारीकियाँ निर्णायक हैं। release: monitoring लेबल ज़रूरी है ताकि Operator इस नियम को उठाए जब चार्ट इसी रिलीज़ नाम से इंस्टॉल हुआ हो — लागू किए गए PrometheusRule के कभी न चलने की यही वजह नंबर 1 है। और runbook एनोटेशन: जिस अलर्ट के साथ प्रक्रिया न जुड़ी हो, उसे हर ऑन-कॉल व्यक्ति अलग तरीके से निपटाएगा, यानी गलत तरीके से।

अलर्ट की राउटिंग: दो सीवियरिटी, पाँच नहीं

Alertmanager मनचाहे जटिल राउटिंग ट्री बनाने देता है। SME क्लस्टर पर दो स्तर पर्याप्त हैं, और बीच का हर स्तर अंत में अनदेखा ही होता है।

alertmanager:
  config:
    route:
      receiver: chat-info
      group_by: ['alertname', 'namespace']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 12h
      routes:
        - matchers: [severity="critical"]
          receiver: astreinte
          repeat_interval: 1h
    inhibit_rules:
      - source_matchers: [alertname="KubeNodeNotReady"]
        target_matchers: [severity="warning"]
        equal: ['node']
    receivers:
      - name: chat-info
        webhook_configs:
          - url: https://chat.example/hooks/monitoring
      - name: astreinte
        webhook_configs:
          - url: https://oncall.example/hooks/critical

• critical → वह नोटिफ़िकेशन जो नींद से जगाए, साथ में एक runbook। कोई उपयोगकर्ता-लक्षण, या नज़दीक आती खराबी।
• warning → कार्य-घंटों में पढ़े जाने वाले चैनल में संदेश, हफ़्ते में एक बार समीक्षा।

inhibit_rules उस पुराने परिदृश्य से बचाते हैं: एक नोड गिरता है, और नोड के अलर्ट के साथ-साथ तीस pod-not-ready अलर्ट आ जाते हैं। हमें उनमें से सिर्फ़ एक चाहिए। रात में भार बढ़ाने वाले शेड्यूल्ड कामों के लिए time_intervals का भी ध्यान रखें — ऐसे अलर्ट से बेहतर है एक स्पष्ट साइलेंस विंडो, जिसे टीम अनदेखा करना सीख जाए।

एक बात अक्सर भूल जाती है: नोटिफ़िकेशन का रास्ता जाँचें, सिर्फ़ नियम नहीं। रद्द किया गया वेबहुक URL बिल्कुल एक स्वस्थ क्लस्टर जैसा व्यवहार करता है। हम एक नकली Watchdog अलर्ट (चार्ट के साथ आता है, यह हमेशा सक्रिय रहता है) किसी « dead man's switch » सेवा की ओर भेजते हैं: अगर पिंग आना बंद हो जाए, तो मतलब मॉनिटरिंग खुद गिर गई है। यही तर्क उस बैकअप पर लागू होता है जिसे कभी रिस्टोर नहीं किया गया — इस विषय को हम अपनी Velero के साथ Kubernetes बैकअप की गाइड में विस्तार से देखते हैं।

असल में इसकी लागत कितनी है

यही सवाल सेल्फ़-होस्टेड और मैनेज्ड सेवा के बीच फ़ैसला करता है। नीचे दिए सार्वजनिक दाम वे हैं जो प्रदाताओं ने 2026 की पतझड़ में दिखाए थे; बजट बनाने से पहले जाँच लें, ये बदलते रहते हैं।

व्यवहार में, हम जो क्लस्टर चलाते हैं, उन पर पूरी मॉनिटरिंग की लागत स्टोरेज में प्रति माह 10 € + कर से भी कम रहती है, और संसाधन में एक-तिहाई नोड के बराबर। असली लागत कहीं और है: शुरुआती सेटिंग के कुछ दिन, और उसके बाद अलर्ट की सफ़ाई का महीने भर में एक घंटा।

SaaS ऑब्ज़र्वेबिलिटी ऑफ़र होस्ट के हिसाब से या इंजेस्ट किए गए वॉल्यूम के हिसाब से बिल करते हैं। वे तब सार्थक हो जाते हैं जब आपके पास कई क्लस्टर हों, एक औपचारिक ऑन-कॉल व्यवस्था हो और मेट्रिक्स, लॉग तथा ट्रेस को एक ही इंटरफ़ेस में जोड़कर देखने की ज़रूरत हो। उससे नीचे kube-prometheus-stack काम कर देता है — ठीक उसी तुलना-तर्क के साथ जो Kubernetes पर PostgreSQL या मैनेज्ड डेटाबेस के चुनाव पर लागू होता है: सेवा की कीमत वह ऑपरेशन समय है जो वह आपको लौटाती है।

जो गलतियाँ हमें सबसे ज़्यादा दिखती हैं

• पर्सिस्टेंट वॉल्यूम के बिना Prometheus। चार्ट खुशी-खुशी emptyDir पर चालू हो जाता है। pod के हर रीस्टार्ट पर इतिहास मिट जाता है, यानी हर पोस्ट-इंसिडेंट विश्लेषण भी।
• Grafana को सत्य का स्रोत मानना। इंटरफ़ेस में हाथ से बनाए डैशबोर्ड PVC के साथ गायब हो जाते हैं। उन्हें grafana_dashboard: "1" लेबल वाले ConfigMap में रखकर Git में वर्ज़न करने से वे पुनरुत्पाद्य बनते हैं — ठीक वैसे ही जैसे GitLab CI/CD पाइपलाइन द्वारा तैनात मैनिफ़ेस्ट।
• कार्डिनैलिटी पर नज़र न रखना। कोई असामान्यीकृत user_id या path लेबल सीरीज़ को हज़ार गुना कर देता है। हम prometheus_tsdb_head_series पर नज़र रखते हैं और चुनी हुई सीमा के पार अलर्ट करते हैं (उदाहरण के लिए ऊपर दिए संसाधनों के लिए 10 लाख सीरीज़)।
• प्रमाणपत्रों पर कोई अलर्ट नहीं। DNS चैलेंज टूटने पर cert-manager चुपचाप फ़ेल हो जाता है। तब अलर्ट उपयोगकर्ताओं से आता है, तीन हफ़्ते बाद।
• for: के बिना अलर्ट। जो नियम एक ही माप-बिंदु पर ट्रिगर हो जाए, वह हर 30 सेकंड के उछाल पर शोर करता है। for: 5m से कम रखने से पहले खुद से सवाल कीजिए।

अगर आप कोई पहले से चल रहा क्लस्टर संभाल रहे हैं, तो पहला उपयोगी अभ्यास डैशबोर्ड जोड़ना नहीं है: पिछले 90 दिनों में ट्रिगर हुए अलर्ट निकालिए और वे सब हटा दीजिए जिनके कारण कभी कोई कार्रवाई नहीं हुई। इन्फ़्रास्ट्रक्चर और मैनेज्ड सर्विसेज़ की सेवाओं पर मिशन की शुरुआत में हम आम तौर पर यही करते हैं, कोई भी नया नियम जोड़ने से पहले। एक भरोसेमंद अलर्ट चैनल हज़ार मेट्रिक्स से बेहतर है।

अक्सर पूछे जाने वाले सवाल

अगर क्लस्टर OVHcloud या Scaleway पर मैनेज्ड है, तो भी Prometheus चाहिए?

हाँ। प्रदाता कंट्रोल प्लेन (API server, etcd, scheduler) की निगरानी करते हैं और आपको उसकी सेहत दिखाते हैं, लेकिन आपकी ऐप्लिकेशनों की नहीं: न आपके 5xx एरर रेट, न भरते जा रहे आपके PVC, न CrashLoopBackOff में पड़े आपके pods। मैनेज्ड दायरा आपके namespaces की सीमा पर खत्म हो जाता है। दूसरी ओर, इसी कारण आप etcd, kubeApiserver*, kubeControllerManager और kubeScheduler के सभी नियम बंद कर सकते हैं: आप उन पर कुछ नहीं कर सकते, और वे झूठे अलर्ट पैदा करते हैं।

Prometheus के लिए कौन-सी रिटेंशन चुनें?

15 दिन पोस्ट-इंसिडेंट जाँच और हफ़्ते-दर-हफ़्ते तुलना की ज़रूरतें पूरी कर देते हैं। उससे आगे ज़रूरत का स्वरूप बदल जाता है: वहाँ बात रुझानों की होती है (क्षमता, मौसमी उतार-चढ़ाव), निदान की नहीं। उसके लिए स्थानीय रिटेंशन नहीं बढ़ाई जाती — Thanos, Mimir या किसी मैनेज्ड सेवा की ओर remote_write जोड़ा जाता है, पहले से एग्रीगेट किए गए मेट्रिक्स के साथ। 30 सेकंड के अंतराल पर 12 महीने का कच्चा डेटा रखना स्टोरेज और मेमोरी खाता है और बदले में कुछ नहीं देता।

Loki या प्रदाता की लॉग सेवा?

Loki ठीक बैठता है अगर आप सब कुछ Grafana में चाहते हैं और ऑब्जेक्ट स्टोरेज की प्रति-GB लागत पर। इसमें ट्यूनिंग चाहिए (रिटेंशन, इंडेक्स, प्रति-टेनेंट सीमाएँ) और एक S3 बकेट संभालना पड़ता है। मैनेज्ड Kubernetes में बिल्ट-इन लॉग सेवाएँ यह संचालन-झंझट बचाती हैं, कीमत है इंजेशन-आधारित बिल जो तब चौंकाता है जब कोई ऐप्लिकेशन लूप में लॉग करने लगे। दोनों हालातों में: प्रति namespace थ्रूपुट पर सीमा लगाइए, वरना किसी लूप में बैठा एक console.log बजट उड़ा देता है।

ऐप्लिकेशन को इंस्ट्रूमेंट किए बिना लेटेंसी पर अलर्ट किया जा सकता है?

आंशिक रूप से। ingress कंट्रोलर और Gateway API के इंप्लीमेंटेशन प्रति रूट लेटेंसी हिस्टोग्राम एक्सपोज़ करते हैं, जो 95वें परसेंटाइल पर थ्रेशोल्ड लगाने के लिए पर्याप्त है। यह ingress-nginx की जगह Gateway API अपनाने के पक्ष में एक और तर्क है। पर यह जानने के लिए कि समय कहाँ बीता, ट्रेस चाहिए, यानी ऐप्लिकेशन-स्तरीय इंस्ट्रूमेंटेशन — आम तौर पर OpenTelemetry SDK के साथ।

हफ़्ते में कितने क्रिटिकल अलर्ट सामान्य हैं?

शून्य, ज़्यादातर हफ़्तों में। हम जो SME क्लस्टर चलाते हैं, उन पर critical अलर्ट एक घटना होती है, रोज़मर्रा नहीं। अगर आपके ऑन-कॉल को हफ़्ते में कई मिलते हैं और उसके बाद कोई सुधारात्मक कार्रवाई नहीं होती, तो समस्या आवृत्ति नहीं है: थ्रेशोल्ड हैं। मॉनिटरिंग की सेहत का सही संकेतक अलर्ट की संख्या नहीं, बल्कि उन अलर्ट का प्रतिशत है जिन पर कोई कार्रवाई हुई।

सारांश में

• kube-prometheus-stack एक कमांड में Prometheus, Alertmanager, Grafana और kubernetes-mixin नियम इंस्टॉल कर देता है; सारा काम values.yaml और नियमों की छँटाई में है।
• हमेशा retention और retentionSize (वॉल्यूम का ≈ 80 %) दोनों तय करें, 3 से 10 नोड के क्लस्टर पर 15 दिन के लिए 50 Gi का PVC रखें।
• Prometheus पर limits.memory लगाएँ, limits.cpu कभी नहीं: कॉम्पैक्शन के दौरान थ्रॉटलिंग झूठे अलर्ट पैदा करती है।
• मैनेज्ड क्लस्टर पर कंट्रोल प्लेन के नियम (etcd, kubeApiserver*, kubeScheduler, kubeControllerManager) बंद कर दें: आप उन पर कुछ नहीं कर सकते।
• दस-बारह इन्फ़्रास्ट्रक्चर अलर्ट रखें, साथ में हर एक्सपोज़्ड सेवा के लिए एक 5xx एरर-रेट नियम, और हर एक में for: तथा runbook एनोटेशन।
• दो सीवियरिटी पर्याप्त हैं: critical जो जगाए, warning जिसकी समीक्षा कार्य-घंटों में हो। ज़्यादा स्तर = अनदेखे स्तर।
• Watchdog अलर्ट पर dead man's switch लगाकर नोटिफ़िकेशन का रास्ता जाँचें: गिरी हुई मॉनिटरिंग एक स्वस्थ क्लस्टर जैसी लगती है।
• स्टोरेज के लिए प्रति माह 10 € + कर से कम और संसाधनों में लगभग एक-तिहाई नोड मानकर चलें; असली लागत ट्यूनिंग का समय है।
• किसी चालू क्लस्टर की मॉनिटरिंग पर बाहरी नज़र चाहिए? हमारी टीम से बात करें या हमसे संपर्क करें।