👩🏿‍🔬 👵🏽 ♀️ प्रोमेथियस के साथ कुबेरनेट्स क्लस्टर की निगरानी 🤶🏾 🍃 🍊

नमस्कार साथियों!

हमने सिर्फ ब्रेंडन बर्न्स की एक दिलचस्प पुस्तक का अनुवाद किया, जो वितरित प्रणालियों के लिए डिज़ाइन पैटर्न के बारे में बात करती है

इसके अलावा, " मास्टेरिंग कुबेरनेट्स " (दूसरा संस्करण) पुस्तक का अनुवाद पहले से ही पूरी तरह से चल रहा है और लेखक की डॉकर के बारे में किताब सितंबर में प्रकाशित होने वाली है, और इसके बारे में एक अलग पोस्ट होगी।

हम मानते हैं कि इस रास्ते पर अगला पड़ाव प्रोमेथियस के बारे में एक किताब है, इसलिए आज हम आपके ध्यान में प्रोमेथियस और कुबेरनेट्स के बीच करीबी बातचीत पर ब्योर्न वेन्ज़ेल के एक संक्षिप्त लेख का अनुवाद करते हैं। कृपया सर्वेक्षण में भाग लेना याद रखें।

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

ऐसे काम के लिए आयोजित उपकरणों में से एक को प्रोमेथियस कहा जाता है। यह क्लाउड नेटिव कम्प्यूटिंग फाउंडेशन द्वारा समर्थित है, मूल रूप से प्रोमेथियस साउंडक्लाउड द्वारा विकसित किया गया था। वैचारिक रूप से, प्रोमेथियस बहुत सरल है:

आर्किटेक्चर

प्रोमेथियस सर्वर काम कर सकता है, उदाहरण के लिए, कुबेरनेट्स क्लस्टर में और एक विशेष फ़ाइल के माध्यम से कॉन्फ़िगरेशन प्राप्त करता है। यह कॉन्फ़िगरेशन, विशेष रूप से, उस जानकारी के बारे में है जिसमें टर्मिनल कहाँ से स्थित है, जिसमें निर्दिष्ट अंतराल के बाद डेटा एकत्र करना है। फिर, प्रोमेथियस सर्वर इन टर्मिनलों से एक विशेष प्रारूप में मैट्रिक्स का अनुरोध करता है (वे आमतौर पर /metrics पर उपलब्ध होते /metrics ) और उन्हें एक समय श्रृंखला डेटाबेस में संग्रहीत करता है। निम्नलिखित एक संक्षिप्त उदाहरण है: प्रत्येक नोड पर एक एजेंट के रूप में तैनात एक node_exporter मॉड्यूल से मैट्रिक्स का अनुरोध करने वाली एक छोटी कॉन्फ़िगरेशन फ़ाइल:

 scrape_configs: - job_name: "node_exporter" scrape_interval: "15s" target_groups: - targets: ['<ip>:9100']

पहले हम नौकरी के नाम job_name को परिभाषित करते हैं, बाद में इस नाम का उपयोग प्रोमेथियस में मैट्रिक्स का अनुरोध करने के लिए किया जा सकता है, फिर scrape_interval डेटा scrape_interval और node_exporter चलाने वाले सर्वरों का एक समूह। अब प्रोमेथियस हर 15 सेकंड में वर्तमान मेट्रिक्स के लिए path /metrics लिए सर्वर से पूछेगा। यह कुछ इस तरह दिखता है:

 # HELP go_gc_duration_seconds A summary of the GC invocation durations. # TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 1.4852e-05 go_gc_duration_seconds{quantile="0.25"} 2.0702e-05 go_gc_duration_seconds{quantile="0.5"} 2.2059e-05 ...

सबसे पहले, मीट्रिक का नाम दिया गया है, फिर हस्ताक्षर (ब्रेसिज़ में जानकारी) और, अंत में, मीट्रिक का मूल्य। सबसे दिलचस्प इन मैट्रिक्स के लिए खोज फ़ंक्शन है। प्रोमेथियस के पास इस उद्देश्य के लिए एक बहुत शक्तिशाली क्वेरी भाषा है ।

प्रोमेथियस का मुख्य विचार, जो पहले से ही ऊपर वर्णित है, यह है: दिए गए अंतराल पर प्रोमेथियस मेट्रिक्स के लिए पोर्ट को पोल करता है और उन्हें एक समय श्रृंखला डेटाबेस में संग्रहीत करता है। यदि प्रोमेथियस मैट्रिक्स को स्वयं नहीं हटा सकता है, तो पुशगेटवे नामक एक और कार्यक्षमता है। पुशगेटवे गेटवे बाहरी नौकरियों द्वारा भेजे गए मैट्रिक्स को स्वीकार करता है, और प्रोमेथियस एक निर्दिष्ट अंतराल पर इस गेटवे से जानकारी एकत्र करता है।

प्रोमेथियस वास्तुकला का एक अन्य वैकल्पिक घटक है alertmanager । alertmanager घटक alertmanager सीमा निर्धारित करने की अनुमति देता है, और उनसे अधिक होने की स्थिति में, ई-मेल, स्लैक या ऑपगेनजी द्वारा सूचनाएं भेजें।

इसके अलावा, प्रोमेथियस सर्वर में कई एकीकृत विशेषताएं हैं , उदाहरण के लिए, यह अमेज़ॅन एपीआई पर ec2 उदाहरणों का अनुरोध कर सकता है या कुबेरनेट्स से पॉड्स, नोड्स और सेवाओं का अनुरोध कर सकता है। इसके कई निर्यातक भी हैं, उदाहरण के लिए, aforementioned node_exporter । ऐसे निर्यातक काम कर सकते हैं, उदाहरण के लिए, नोड पर जहां MySQL जैसे एप्लिकेशन इंस्टॉल किए जाते हैं और मैट्रिक्स के लिए आवेदन को प्रदूषित करने और उन्हें टर्मिनल / मेट्रिक्स पर प्रदान करने के लिए दिए गए अंतराल पर, और प्रोमेथियस सर्वर वहां से इन मैट्रिक्स को एकत्र कर सकते हैं।

इसके अलावा, अपने स्वयं के निर्यातक को लिखना मुश्किल नहीं है - उदाहरण के लिए, एक एप्लिकेशन के लिए जो मैट्रिक्स प्रदान करता है जैसे कि जेवीएम जानकारी। उदाहरण के लिए, ऐसे मेट्रिक्स को निर्यात करने के लिए प्रोमेथियस द्वारा विकसित एक ऐसी लाइब्रेरी है। इस लाइब्रेरी का उपयोग स्प्रिंग के साथ संयोजन के रूप में किया जा सकता है, और आपको अपने स्वयं के मैट्रिक्स को परिभाषित करने की भी अनुमति देता है। client_java पृष्ठ से एक उदाहरण यहाँ दिया गया है:

 @Controller public class MyController { @RequestMapping("/") @PrometheusTimeMethod(name = "my_controller_path_duration_seconds", help = "Some helpful info here") public Object handleMain() { //  - } }

यह विधि की अवधि का वर्णन करने वाला एक मीट्रिक है, और अन्य मीट्रिक अब टर्मिनल के माध्यम से या पुशगेटवे के माध्यम से प्रदान किए जा सकते हैं।

कुबेरनेट्स क्लस्टर में उपयोग

जैसा कि मैंने उल्लेख किया, कुबेरनेट्स क्लस्टर में प्रोमेथियस का उपयोग करने के लिए चूल्हा, नोड और सेवा से जानकारी निकालने के लिए एकीकृत क्षमताएं हैं। सबसे दिलचस्प बात, कुबेरनेट्स को विशेष रूप से प्रोमेथियस के साथ काम करने के लिए डिज़ाइन किया गया है। उदाहरण के लिए, kubelet और kube-apiserver प्रोमेथियस में kube-apiserver मैट्रिक्स प्रदान करते हैं, इसलिए निगरानी बहुत सरल है।

इस उदाहरण में, शुरुआत के लिए, मैं आधिकारिक हेल्म चार्ट का उपयोग करता हूं।

अपने लिए, मैंने डिफ़ॉल्ट हेलम चार्ट के विन्यास को थोड़ा बदल दिया है। सबसे पहले, मुझे प्रोमेथियस इंस्टॉलेशन में rbac को सक्रिय करने की आवश्यकता थी, अन्यथा प्रोमेथियस kube-apiserver से जानकारी एकत्र करने में सक्षम नहीं था। इसलिए, मैंने अपना स्वयं का मान लिखा है। ओएमएल फ़ाइल, जो बताता है कि पतवार चार्ट कैसे प्रदर्शित किया जाना चाहिए।

मैंने सबसे सरल परिवर्तन किए:

alertmanager.enabled: false , अर्थात, क्लस्टर में अलर्टमैनगर की तैनाती को रद्द कर दिया है (मैं अलर्टमैनगर का उपयोग नहीं करने वाला था, मुझे लगता है कि ग्राफ्टाना के साथ अलर्ट कॉन्फ़िगर करना आसान है)
kubeStateMetrics.enabled: false मुझे लगता है कि ये मैट्रिक्स अधिकतम संख्या में चूल्हों के बारे में कुछ जानकारी लौटाते हैं। जब आप पहली बार सिस्टम शुरू करते हैं, तो यह जानकारी मेरे लिए महत्वपूर्ण नहीं है
server.persistentVolume.enabled: false जब तक मैं डिफ़ॉल्ट रूप से एक निरंतर मात्रा कॉन्फ़िगर किया गया है
मैंने प्रोमेथियस में सूचना संग्रह के विन्यास को बदल दिया, क्योंकि यह जीथब पर पुल अनुरोध में किया गया था। तथ्य यह है कि कुबेरनेट्स v1.7 में, cAdvisor मेट्रिक्स एक अलग पोर्ट पर काम करते हैं।

उसके बाद, आप हेल्म का उपयोग करके प्रोमेथियस शुरू कर सकते हैं:

helm install stable/prometheus --name prometheus-monitoring -f prometheus-values.yaml

तो हम प्रोमेथियस सर्वर को स्थापित करते हैं, और प्रत्येक नोड पर - नोड_एक्सपोर्ट के तहत स्थापित करते हैं। अब आप प्रोमेथियस वेब GUI पर जा सकते हैं और कुछ जानकारी देख सकते हैं:

kubectl port-forward <prometheus-server-pod> 9090

निम्नलिखित स्क्रीनशॉट किन उद्देश्यों के लिए दिखाते हैं कि प्रोमेथियस जानकारी एकत्र करता है (स्थिति / लक्ष्य), और जब जानकारी को अंतिम बार कई बार शूट किया गया था:

यहां आप देख सकते हैं कि कैसे प्रोमेथियस एपसर, नोड्स, एक कैडवाइजर से मैट्रिक्स का अनुरोध कर रहा है जो नोड्स और कुबेरनेट्स सेवा समापन बिंदुओं पर चलता है। आप ग्राफ में जाकर विस्तार से देख सकते हैं और एक क्वेरी लिखकर उस जानकारी को देख सकते हैं जिसमें हम रुचि रखते हैं:

यहाँ, उदाहरण के लिए, हम आरोह बिंदु "/" पर निःशुल्क संग्रहण देखते हैं। आरेख के निचले भाग पर, हस्ताक्षर जोड़े जाते हैं जो प्रोमेथियस द्वारा जोड़े जाते हैं या पहले से ही नोड_एक्सपोर्ट पर उपलब्ध हैं। हम केवल माउंट बिंदु "/" का अनुरोध करने के लिए इन हस्ताक्षरों का उपयोग करते हैं।

एनोटेशन के साथ कस्टम मेट्रिक्स

जैसा कि पहले स्क्रीनशॉट में दिखाया गया है, जहां प्रोमेथियस जिन अनुरोधों के लिए मेट्रिक्स अनुरोध कर रहा है, वे व्युत्पन्न हैं, क्लस्टर में काम करने वाले चूल्हा के लिए एक मीट्रिक भी है। प्रोमेथियस की अच्छी विशेषताओं में से एक पूरे चूल्हा से जानकारी लेने की क्षमता है। अगर चूल्हा में कंटेनर प्रोमेथियस मेट्रिक्स प्रदान करता है, तो हम इन मेट्रिक्स को प्रोमेथियस का उपयोग करके स्वचालित रूप से एकत्र कर सकते हैं। केवल एक चीज जिसे हमें ध्यान रखने की आवश्यकता है वह है स्थापना को दो एनोटेशन के साथ प्रदान करना; मेरे मामले में nginx-ingress-controller इस बॉक्स से बाहर करता है:

 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-ingress-controller namespace: ingress-nginx spec: replicas: 1 selector: matchLabels: app: ingress-nginx template: metadata: labels: app: ingress-nginx annotations: prometheus.io/port: '10254' prometheus.io/scrape: 'true' ...

यहाँ हम देखते हैं कि परिनियोजन टेम्पलेट दो प्रोमेथियस एनोटेशन के साथ आता है। पहले पोर्ट का वर्णन करता है जिसके माध्यम से प्रोमेथियस को मैट्रिक्स का अनुरोध करना चाहिए, और दूसरा डेटा संग्रह की कार्यक्षमता को सक्रिय करता है। अब, प्रोमेथियस Kubernetes Api-Server पॉड्स को सूचना एकत्र करने के लिए अनुरोध करता है और टर्मिनल / मेट्रिक्स से जानकारी एकत्र करने का प्रयास करता है।

संघीय कार्य

हमारे पास एक परियोजना है जिसमें प्रोमेथियस एक फ़ेडरेटेड मोड में उपयोग किया जाता है। विचार यह है: हम केवल उस जानकारी को एकत्र करते हैं जो केवल क्लस्टर के भीतर से उपलब्ध है (या क्लस्टर के भीतर से इस जानकारी को इकट्ठा करना आसान है), फ़ेडरेटेड मोड को सक्षम करें और क्लस्टर के बाहर स्थापित दूसरे प्रोमेथियस का उपयोग करके इस जानकारी को प्राप्त करें। इस प्रकार, एक बार में कई कुबेरनेट समूहों से जानकारी एकत्र करना संभव है, अन्य घटकों को कैप्चर करना जो इस क्लस्टर के भीतर से पहुंच योग्य नहीं हैं या इस क्लस्टर से संबंधित नहीं हैं। इसके अलावा, फिर क्लस्टर में एकत्रित डेटा को लंबे समय तक संग्रहीत करना आवश्यक नहीं है, और यदि क्लस्टर के साथ कुछ गलत होता है, तो हम क्लस्टर के बाहर से, उदाहरण के लिए, कुछ जानकारी एकत्र कर सकते हैं।

प्रोमेथियस के साथ कुबेरनेट्स क्लस्टर की निगरानी

आर्किटेक्चर

कुबेरनेट्स क्लस्टर में उपयोग

एनोटेशन के साथ कस्टम मेट्रिक्स

संघीय कार्य

More articles: