कुबर्नेट्स क्लस्टरचे निरीक्षण करणे: प्रोमिथियसचे विहंगावलोकन आणि परिचय

कुबर्नेट्स मॉनिटरिंगची संकल्पना विचारात घ्या, प्रोमिथियस टूलशी परिचित व्हा आणि अलर्टिंगबद्दल बोला.

देखरेखीचा विषय प्रचंड आहे, तो एका लेखात वेगळे करता येणार नाही. या मजकुराचा उद्देश साधने, संकल्पना आणि दृष्टिकोन यांचे विहंगावलोकन प्रदान करणे आहे.

लेखाची सामग्री पासून एक पिळणे आहे "स्लर्म" शाळेचे खुले व्याख्यान. तुम्हाला पूर्ण कोर्स करायचा असेल तर - ऑन कोर्ससाठी साइन अप करा कुबर्नेट्समधील पायाभूत सुविधांचे निरीक्षण आणि लॉगिंग.

कुबर्नेट्स क्लस्टरमध्ये कशाचे परीक्षण केले जाते

भौतिक सर्व्हर. Kubernetes क्लस्टर त्याच्या सर्व्हरवर तैनात असल्यास, आपण त्यांच्या आरोग्यावर लक्ष ठेवणे आवश्यक आहे. Zabbix हे काम हाताळते; जर तुम्ही त्याच्याबरोबर काम केले तर तुम्हाला नकार देण्याची गरज नाही, कोणताही संघर्ष होणार नाही. हे Zabbix आहे जे आमच्या सर्व्हरच्या स्थितीवर लक्ष ठेवते.

क्लस्टर स्तरावर देखरेख करण्यासाठी पुढे जाऊया.

नियंत्रण विमान घटक: API, शेड्युलर आणि इतर. किमान, तुम्हाला सर्व्हर किंवा etcd चा API 0 पेक्षा जास्त आहे याची खात्री करणे आवश्यक आहे. Etcd बरेच मेट्रिक्स परत करू शकते: ज्या डिस्कवर ते फिरत आहे त्याद्वारे, त्याच्या etcd क्लस्टरच्या आरोग्याद्वारे आणि इतर.

गोदी कामगार बर्याच काळापूर्वी दिसले आणि प्रत्येकाला त्याच्या समस्या चांगल्या प्रकारे माहित आहेत: बरेच कंटेनर फ्रीझ आणि इतर समस्या निर्माण करतात. म्हणून, डॉकर स्वतः, एक प्रणाली म्हणून, कमीतकमी उपलब्धतेसाठी देखील नियंत्रित केले पाहिजे.

डीएनएस. क्लस्टरमध्ये DNS बंद पडल्यास, त्यानंतर संपूर्ण डिस्कव्हरी सेवा बंद पडेल, पॉड्स ते पॉड्सवर कॉल करणे थांबेल. माझ्या सराव मध्ये, अशा कोणत्याही समस्या नव्हत्या, परंतु याचा अर्थ असा नाही की DNS च्या स्थितीचे परीक्षण करण्याची आवश्यकता नाही. विनंती विलंब आणि काही इतर मेट्रिक्स CoreDNS वर ट्रॅक केल्या जाऊ शकतात.

प्रवेश. प्रकल्पासाठी प्रवेश बिंदू म्हणून प्रवेशाची उपलब्धता (इनग्रेस कंट्रोलरसह) नियंत्रित करणे आवश्यक आहे.

क्लस्टरचे मुख्य घटक काढून टाकले गेले आहेत - आता आपण अमूर्ततेच्या पातळीवर जाऊ या.

असे दिसते की ऍप्लिकेशन्स पॉड्समध्ये चालतात, याचा अर्थ त्यांना नियंत्रित करणे आवश्यक आहे, परंतु प्रत्यक्षात ते तसे नाहीत. शेंगा तात्पुरत्या आहेत: आज ते एका सर्व्हरवर चालतात, उद्या दुसऱ्यावर; आज त्यापैकी 10 आहेत, उद्या 2. त्यामुळे शेंगांवर कोणीही लक्ष ठेवत नाही. मायक्रोसर्व्हिस आर्किटेक्चरमध्ये, संपूर्णपणे ऍप्लिकेशनची उपलब्धता नियंत्रित करणे अधिक महत्त्वाचे आहे. विशेषतः, सेवा समाप्ती बिंदूंची उपलब्धता तपासा: काही कार्य करते का? अर्ज उपलब्ध झाला, तर त्यामागे काय होते, आता किती प्रतिकृती आहेत- हे दुसऱ्या क्रमाचे प्रश्न आहेत. वैयक्तिक घटनांचे निरीक्षण करण्याची आवश्यकता नाही.

शेवटच्या स्तरावर, आपल्याला अनुप्रयोगाचे ऑपरेशन स्वतः नियंत्रित करणे आवश्यक आहे, व्यवसाय मेट्रिक्स घेणे आवश्यक आहे: ऑर्डरची संख्या, वापरकर्ता वर्तन इ.

Prometheus

क्लस्टरचे निरीक्षण करण्यासाठी सर्वोत्तम प्रणाली आहे Prometheus. मला असे कोणतेही साधन माहित नाही जे प्रॉमिथियसशी गुणवत्ता आणि वापर सुलभतेच्या बाबतीत जुळेल. लवचिक पायाभूत सुविधांसाठी हे उत्तम आहे, म्हणून जेव्हा ते “कुबर्नेट्स मॉनिटरिंग” म्हणतात तेव्हा त्यांचा अर्थ सामान्यतः प्रोमिथियस असा होतो.

Prometheus सह प्रारंभ करण्यासाठी दोन पर्याय आहेत: Helm वापरून, आपण नियमित Prometheus किंवा Prometheus ऑपरेटर स्थापित करू शकता.

1. नियमित प्रोमिथियस. त्याच्याबरोबर सर्व काही ठीक आहे, परंतु आपल्याला कॉन्फिगमॅप कॉन्फिगर करणे आवश्यक आहे - खरं तर, मायक्रोसर्व्हिस आर्किटेक्चरच्या आधी आम्ही पूर्वी केल्याप्रमाणे मजकूर-आधारित कॉन्फिगरेशन फायली लिहा.
2. प्रोमिथियस ऑपरेटर थोडे अधिक पसरलेले आहे, अंतर्गत तर्कशास्त्राच्या दृष्टीने थोडे अधिक क्लिष्ट आहे, परंतु त्याच्यासह कार्य करणे सोपे आहे: क्लस्टरमध्ये स्वतंत्र वस्तू आहेत, अॅब्स्ट्रॅक्शन जोडले आहेत, त्यामुळे ते नियंत्रित आणि कॉन्फिगर करणे अधिक सोयीस्कर आहेत.

उत्पादन समजून घेण्यासाठी, मी प्रथम नियमित प्रोमिथियस स्थापित करण्याची शिफारस करतो. तुम्हाला कॉन्फिगरद्वारे सर्व काही कॉन्फिगर करावे लागेल, परंतु हे फायदेशीर ठरेल: कशाचे आहे आणि ते कसे कॉन्फिगर केले आहे ते तुम्हाला समजेल. प्रोमिथियस ऑपरेटरमध्ये, तुम्ही ताबडतोब अ‍ॅब्स्ट्रॅक्शन वर जाल, जरी तुमची इच्छा असल्यास तुम्ही खोलवर देखील जाऊ शकता.

प्रोमिथियस कुबेरनेट्ससह चांगले समाकलित आहे: ते API सर्व्हरमध्ये प्रवेश करू आणि संवाद साधू शकते.

प्रोमिथियस लोकप्रिय आहे, म्हणूनच मोठ्या संख्येने अनुप्रयोग आणि प्रोग्रामिंग भाषा त्यास समर्थन देतात. समर्थन आवश्यक आहे, कारण Prometheus चे स्वतःचे मेट्रिक्स स्वरूप आहे, आणि ते हस्तांतरित करण्यासाठी, तुम्हाला एकतर ऍप्लिकेशनमध्ये लायब्ररी किंवा रेडीमेड एक्सपोर्टरची आवश्यकता आहे. आणि असे काही निर्यातदार आहेत. उदाहरणार्थ, PostgreSQL निर्यातक आहे: तो PostgreSQL कडून डेटा घेतो आणि प्रोमिथियस फॉरमॅटमध्ये रूपांतरित करतो जेणेकरून प्रोमिथियस त्याच्यासोबत काम करू शकेल.

प्रोमिथियस आर्किटेक्चर

प्रोमिथियस सर्व्हर मागील टोक आहे, प्रोमिथियसचा मेंदू. मेट्रिक्स येथे संग्रहित आणि प्रक्रिया केल्या जातात.

मेट्रिक्स टाइम सीरीज डेटाबेस (TSDB) मध्ये संग्रहित केले जातात. TSDB हा वेगळा डेटाबेस नाही, तर Prometheus मध्ये एम्बेड केलेले Go भाषेतील पॅकेज आहे. ढोबळपणे सांगायचे तर, सर्व काही एका बायनरीमध्ये आहे.

TSDB मध्ये जास्त काळ डेटा साठवू नका

Prometheus पायाभूत सुविधा मेट्रिक्सच्या दीर्घकालीन संचयनासाठी योग्य नाही. डीफॉल्ट धारणा कालावधी 15 दिवस आहे. तुम्ही ही मर्यादा ओलांडू शकता, परंतु लक्षात ठेवा: तुम्ही TSDB मध्ये जितका जास्त डेटा संग्रहित कराल आणि ते जितके जास्त काळ कराल तितके जास्त संसाधने वापरतील. प्रोमिथियसमध्ये ऐतिहासिक डेटा संग्रहित करणे ही वाईट प्रथा मानली जाते.

जर तुमच्याकडे प्रचंड रहदारी असेल, मेट्रिक्सची संख्या प्रति सेकंद शेकडो हजारो असेल, तर डिस्क स्पेस किंवा कालावधीनुसार त्यांचे स्टोरेज मर्यादित करणे चांगले आहे. सहसा, "हॉट डेटा" TSDB, मेट्रिक्समध्ये फक्त काही तासांमध्ये संग्रहित केला जातो. दीर्घ संचयनासाठी, बाह्य संचयन त्या डेटाबेसमध्ये वापरले जाते जे यासाठी खरोखर योग्य आहेत, उदाहरणार्थ, InfluxDB, ClickHouse आणि असेच. मी क्लिकहाऊसबद्दल अधिक चांगली पुनरावलोकने पाहिली.

प्रोमिथियस सर्व्हर मॉडेलवर कार्य करते खेचणे: आम्ही त्याला दिलेल्या शेवटच्या बिंदूंवर तो मेट्रिक्ससाठी जातो. ते म्हणाले: “एपीआय सर्व्हरवर जा”, आणि तो प्रत्येक n-व्या सेकंदाला तिथे जातो आणि मेट्रिक्स घेतो.

स्क्रॅपिंग कालावधी दरम्यान दिसू शकणार्‍या लहान आयुष्याच्या (नोकरी किंवा क्रॉन जॉब) वस्तूंसाठी, पुशगेटवे घटक आहे. शॉर्ट-टर्म ऑब्जेक्ट्सचे मेट्रिक्स त्यात ढकलले जातात: नोकरी वाढली आहे, कृती केली आहे, मेट्रिक्स पुशगेटवेवर पाठवले आहेत आणि पूर्ण झाले आहेत. थोड्या वेळाने, प्रोमिथियस स्वतःच्या गतीने खाली येईल आणि पुशगेटवेवरून हे मेट्रिक्स उचलेल.

Prometheus मध्ये सूचना कॉन्फिगर करण्यासाठी एक वेगळा घटक आहे - अलर्ट मॅनेजर. आणि चेतावणी नियम. उदाहरणार्थ, सर्व्हर API 0 असल्यास तुम्हाला एक अलर्ट तयार करणे आवश्यक आहे. जेव्हा इव्हेंट फायर होतो, तेव्हा अॅलर्ट पुढील डिस्पॅचसाठी अॅलर्ट मॅनेजरकडे पाठवला जातो. अॅलर्ट मॅनेजरकडे अगदी लवचिक राउटिंग सेटिंग्ज आहेत: अॅलर्टचा एक गट अॅडमिनच्या टेलिग्राम चॅटवर, दुसरा डेव्हलपरच्या चॅटवर आणि तिसरा इन्फ्रास्ट्रक्चर कामगारांच्या चॅटवर पाठवला जाऊ शकतो. सूचना स्लॅक, टेलिग्राम, ईमेल आणि इतर चॅनेलवर पाठवल्या जाऊ शकतात.

आणि शेवटी, मी तुम्हाला प्रोमिथियस किलर वैशिष्ट्याबद्दल सांगेन - शोध. प्रोमिथियससह काम करताना, आपल्याला निरीक्षणासाठी ऑब्जेक्ट्सचे विशिष्ट पत्ते निर्दिष्ट करण्याची आवश्यकता नाही, त्यांचा प्रकार सेट करणे पुरेसे आहे. म्हणजेच, तुम्हाला "येथे IP पत्ता आहे, येथे पोर्ट - मॉनिटर आहे" असे लिहिण्याची गरज नाही, त्याऐवजी, या वस्तू शोधण्यासाठी कोणत्या तत्त्वांनुसार तुम्हाला हे ठरवावे लागेल (लक्ष्य - गोल). प्रोमिथियस स्वतः, सध्या कोणत्या वस्तू सक्रिय आहेत यावर अवलंबून, आवश्यक वस्तू खेचतो आणि त्यांना मॉनिटरिंगमध्ये जोडतो.

हा दृष्टीकोन कुबर्नेट्सच्या संरचनेत योग्य प्रकारे बसतो, जिथे सर्व काही तरंगते: आज 10 सर्व्हर आहेत, उद्या 3. प्रत्येक वेळी सर्व्हरचा IP पत्ता निर्दिष्ट न करण्यासाठी, त्यांनी तो कसा शोधायचा ते एकदा लिहिले - आणि डिस्कव्हरिंग ते करेल .

प्रोमिथियस भाषेला म्हणतात PromQL. या भाषेचा वापर करून, तुम्ही विशिष्ट मेट्रिक्सची मूल्ये मिळवू शकता आणि नंतर त्यांचे रूपांतर करू शकता, त्यावर आधारित विश्लेषणात्मक गणना तयार करू शकता.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

प्रोमिथियस वेब इंटरफेस

प्रोमिथियसचा स्वतःचा, अगदी मिनिमलिस्टिक वेब इंटरफेस आहे. केवळ डीबग किंवा प्रदर्शनासाठी योग्य.

एक्सप्रेशन लाइनमध्ये, तुम्ही PromQL भाषेत क्वेरी लिहू शकता.

अॅलर्ट टॅबमध्ये अलर्टिंग नियम असतात आणि त्यांच्या तीन स्थिती आहेत:

1. निष्क्रिय - जर अलर्ट याक्षणी सक्रिय नसेल, म्हणजे, सर्वकाही ठीक आहे आणि ते कार्य करत नाही;
2. प्रलंबित - हे असे आहे की जर अलर्ट कार्य करत असेल, परंतु पाठवणे अद्याप पास झाले नाही. नेटवर्क ब्लिंकिंगची भरपाई करण्यासाठी विलंब सेट केला आहे: जर निर्दिष्ट सेवा एका मिनिटात वाढली असेल, तर अलार्म अद्याप वाजला जाऊ नये;
3. गोळीबार ही तिसरी स्थिती असते जेव्हा अलर्ट दिवा लागतो आणि संदेश पाठवतो.

स्टेटस मेनूमध्ये तुम्हाला प्रोमिथियस काय आहे याविषयी माहिती मिळू शकेल. लक्ष्य (लक्ष्य) मध्ये संक्रमण देखील आहे, ज्याबद्दल आम्ही वर बोललो.

प्रोमिथियस इंटरफेसच्या अधिक तपशीलवार विहंगावलोकनसाठी, पहा कुबर्नेट्स क्लस्टरच्या देखरेखीवर स्लर्मच्या व्याख्यानात.

Grafana सह एकत्रीकरण

प्रोमिथियस वेब इंटरफेसमध्ये, तुम्हाला सुंदर आणि समजण्याजोगे आलेख सापडणार नाहीत ज्यावरून तुम्ही क्लस्टरच्या स्थितीबद्दल निष्कर्ष काढू शकता. त्यांना तयार करण्यासाठी, प्रोमिथियस ग्राफानासह एकत्रित केले आहे. आम्हाला असे डॅशबोर्ड मिळतात.

प्रोमिथियस आणि ग्राफाना एकत्रीकरण सेट करणे अजिबात कठीण नाही, आपण दस्तऐवजीकरणात सूचना शोधू शकता: प्रोमिथियससाठी ग्राफाना समर्थनबरं, मी हे संपवतो.

पुढील लेखांमध्ये, आम्ही निरीक्षणाचा विषय सुरू ठेवू: आम्ही ग्राफना लोकी आणि पर्यायी साधनांचा वापर करून नोंदी गोळा आणि विश्लेषण करण्याबद्दल बोलू.

लेखक: मार्सेल इब्राएव, प्रमाणित कुबर्नेट्स प्रशासक, कंपनीत अभियंता सराव साउथब्रिज, स्पीकर आणि कोर्स डेव्हलपर स्लर्म.

स्त्रोत: www.habr.com