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

Kubernetes निगरानी को अवधारणा विचार गर्नुहोस्, Prometheus उपकरण संग परिचित हुनुहोस्, र सतर्कता बारे कुरा गर्नुहोस्।

अनुगमनको विषय ठूलो छ, यसलाई एउटै लेखमा छुट्याउन सकिँदैन। यस पाठको उद्देश्य उपकरणहरू, अवधारणाहरू र दृष्टिकोणहरूको एक सिंहावलोकन प्रदान गर्नु हो।

लेखको सामग्री एक निचोड हो विद्यालय "स्लर्म" को खुला व्याख्यान। यदि तपाइँ पूर्ण पाठ्यक्रम लिन चाहनुहुन्छ भने - पाठ्यक्रमको लागि साइन अप गर्नुहोस् Kubernetes मा अनुगमन र लगिङ पूर्वाधार.

Kubernetes क्लस्टरमा के निगरानी गरिन्छ

भौतिक सर्भरहरू। यदि Kubernetes क्लस्टर यसको सर्भरमा तैनात गरिएको छ भने, तपाईंले तिनीहरूको स्वास्थ्य निगरानी गर्न आवश्यक छ। Zabbix ले यो कार्य ह्यान्डल गर्छ; यदि तपाइँ उहाँसँग काम गर्नुहुन्छ भने, तपाइँलाई अस्वीकार गर्न आवश्यक छैन, त्यहाँ कुनै विवाद हुनेछैन। यो Zabbix हो जसले हाम्रो सर्भरहरूको अवस्थालाई निगरानी गर्दछ।

क्लस्टर स्तरमा अनुगमन गर्न अगाडि बढौं।

नियन्त्रण विमान घटकहरू: API, अनुसूचक र अन्य। न्यूनतममा, तपाईंले सर्भर वा etcd को API ० भन्दा ठुलो छ भनी सुनिश्चित गर्न आवश्यक छ। Etcd ले धेरै मेट्रिकहरू फिर्ता गर्न सक्छ: डिस्कहरू जसमा यो घुमिरहेको छ, यसको etcd क्लस्टरको स्वास्थ्यद्वारा, र अन्य।

डकर लामो समय पहिले देखा पर्‍यो र सबैलाई यसको समस्याहरू बारे राम्ररी थाहा छ: धेरै कन्टेनरहरूले फ्रिज र अन्य समस्याहरू उत्पन्न गर्छन्। त्यसकारण, डकर आफैं, एक प्रणालीको रूपमा, कम्तिमा उपलब्धताको लागि पनि नियन्त्रण गरिनु पर्छ।

DNS यदि DNS क्लस्टरमा बन्द भयो भने, त्यसपछि सम्पूर्ण डिस्कभरी सेवा बन्द हुनेछ, पोडबाट पोडहरूमा कलहरू काम गर्न बन्द हुनेछन्। मेरो अभ्यासमा, त्यस्ता कुनै समस्याहरू थिएनन्, तर यसको मतलब यो होइन कि DNS को अवस्था अनुगमन गर्न आवश्यक छैन। अनुरोध विलम्बता र केहि अन्य मेट्रिक्स CoreDNS मा ट्र्याक गर्न सकिन्छ।

प्रवेश। यो परियोजनामा ​​प्रवेश बिन्दुको रूपमा प्रवेश (इन्ग्रेस कन्ट्रोलर सहित) को उपलब्धता नियन्त्रण गर्न आवश्यक छ।

क्लस्टरको मुख्य कम्पोनेन्टहरू भत्काइएका छन् - अब हामी एब्स्ट्र्याक्शनको स्तरमा जाऔं।

यस्तो देखिन्छ कि एप्लिकेसनहरू पोडहरूमा चल्छन्, जसको मतलब उनीहरूलाई नियन्त्रण गर्न आवश्यक छ, तर वास्तवमा तिनीहरू छैनन्। पोडहरू क्षणिक हुन्छन्: आज तिनीहरू एउटा सर्भरमा चल्छन्, भोलि अर्कोमा; आज तीमध्ये 10 छन्, भोलि 2। त्यसैले, कोही पनि पोडहरू निगरानी गर्दैन। माइक्रोसर्भिस आर्किटेक्चर भित्र, सम्पूर्ण रूपमा एप्लिकेसनको उपलब्धतालाई नियन्त्रण गर्न अझ महत्त्वपूर्ण छ। विशेष गरी, सेवा अन्त्य बिन्दुहरूको उपलब्धता जाँच गर्नुहोस्: के केहि काम गर्दछ? यदि अनुप्रयोग उपलब्ध छ भने, त्यसपछि यसको पछाडि के हुन्छ, कति प्रतिकृतिहरू छन् - यी दोस्रो अर्डरका प्रश्नहरू हुन्। व्यक्तिगत घटनाहरू निगरानी गर्न आवश्यक छैन।

अन्तिम स्तरमा, तपाईंले अनुप्रयोगको सञ्चालन आफैं नियन्त्रण गर्न आवश्यक छ, व्यापार मेट्रिक्स लिनुहोस्: अर्डरहरूको संख्या, प्रयोगकर्ता व्यवहार, र यस्तै।

Prometheus

क्लस्टर अनुगमनको लागि उत्तम प्रणाली हो Prometheus। मलाई कुनै पनि उपकरण थाहा छैन जुन गुणस्तर र प्रयोगको सहजताको हिसाबले प्रोमेथियससँग मेल खान्छ। यो लचिलो पूर्वाधारको लागि उत्कृष्ट छ, त्यसैले जब तिनीहरूले "कुबर्नेट्स मोनिटरिङ" भन्छन्, तिनीहरू सामान्यतया प्रोमेथियसको अर्थ हुन्।

Prometheus को साथ सुरु गर्न को लागी केहि विकल्पहरू छन्: Helm को प्रयोग गरेर, तपाइँ एक नियमित Prometheus वा Prometheus अपरेटर स्थापना गर्न सक्नुहुन्छ।

1. नियमित प्रोमेथियस। उहाँसँग सबै कुरा ठीक छ, तर तपाईंले कन्फिगम्याप कन्फिगर गर्न आवश्यक छ - वास्तवमा, पाठ-आधारित कन्फिगरेसन फाइलहरू लेख्नुहोस्, जस्तै हामीले माइक्रोसर्भिस आर्किटेक्चर अघि गर्यौं।
2. प्रोमेथियस अपरेटर अलि बढी फैलिएको छ, आन्तरिक तर्कको सन्दर्भमा अलि बढी जटिल छ, तर योसँग काम गर्न सजिलो छ: त्यहाँ छुट्टै वस्तुहरू छन्, एब्स्ट्र्याक्सनहरू क्लस्टरमा थपिएका छन्, त्यसैले तिनीहरू नियन्त्रण र कन्फिगर गर्न धेरै सुविधाजनक छन्।

उत्पादन बुझ्नको लागि, म पहिले नियमित प्रोमेथियस स्थापना गर्न सिफारिस गर्दछु। तपाईंले कन्फिगर मार्फत सबै कुरा कन्फिगर गर्नुपर्नेछ, तर यो लाभदायक हुनेछ: तपाईंले के के हो र कसरी कन्फिगर गरिएको छ भनेर पत्ता लगाउनुहुनेछ। प्रोमिथियस अपरेटरमा, तपाईं तुरुन्तै एक अमूर्त उच्चमा उठ्नुहुन्छ, यद्यपि तपाईं चाहानुहुन्छ भने गहिराइमा पनि जान सक्नुहुन्छ।

प्रोमेथियस कुबेरनेटसँग राम्रोसँग एकीकृत छ: यसले API सर्भरसँग पहुँच र अन्तरक्रिया गर्न सक्छ।

प्रोमेथियस लोकप्रिय छ, त्यसैले धेरै संख्यामा अनुप्रयोग र प्रोग्रामिङ भाषाहरूले यसलाई समर्थन गर्दछ। समर्थन आवश्यक छ, किनकि प्रोमेथियसको आफ्नै मेट्रिक्स ढाँचा छ, र यसलाई स्थानान्तरण गर्न, तपाइँलाई अनुप्रयोग भित्र पुस्तकालय वा तयार निर्यातकर्ता चाहिन्छ। र त्यहाँ त्यस्ता निर्यातकर्ताहरू धेरै छन्। उदाहरण को लागी, त्यहाँ PostgreSQL निर्यातक छ: यसले PostgreSQL बाट डाटा लिन्छ र यसलाई Prometheus ढाँचामा रूपान्तरण गर्दछ ताकि Prometheus सँग काम गर्न सकून्।

प्रोमेथियस वास्तुकला

प्रोमेथियस सर्भर पछाडिको छेउ हो, प्रोमेथियसको मस्तिष्क। मेट्रिक्स यहाँ भण्डारण र प्रशोधन गरिन्छ।

मेट्रिक्स समय श्रृंखला डाटाबेस (TSDB) मा भण्डारण गरिन्छ। TSDB छुट्टै डाटाबेस होइन, तर गो भाषाको प्याकेज हो जुन प्रोमेथियसमा इम्बेड गरिएको छ। लगभग बोल्दै, सबै एक बाइनरी मा छ।

लामो समयको लागि TSDB मा डाटा भण्डार नगर्नुहोस्

प्रोमेथियस पूर्वाधार मेट्रिक्सको दीर्घकालीन भण्डारणको लागि उपयुक्त छैन। पूर्वनिर्धारित अवधारण अवधि 15 दिन हो। तपाईंले यो सीमा नाघ्न सक्नुहुन्छ, तर ध्यान राख्नुहोस्: तपाईंले TSDB मा जति धेरै डाटा भण्डारण गर्नुहुन्छ र जति लामो समयसम्म गर्नुहुन्छ, त्यति धेरै स्रोतहरू खपत हुनेछ। Prometheus मा ऐतिहासिक डाटा भण्डारण खराब अभ्यास मानिन्छ।

यदि तपाईंसँग ठूलो ट्राफिक छ भने, मेट्रिक्सको संख्या सयौं हजार प्रति सेकेन्ड छ, त्यसपछि तिनीहरूको भण्डारण डिस्क स्थान वा अवधि द्वारा सीमित गर्न राम्रो छ। सामान्यतया, "तातो डाटा" TSDB मा भण्डारण गरिन्छ, मेट्रिक्स केही घण्टामा। लामो भण्डारणको लागि, बाह्य भण्डारण ती डाटाबेसहरूमा प्रयोग गरिन्छ जुन वास्तवमै यसको लागि उपयुक्त छ, उदाहरणका लागि, InfluxDB, ClickHouse, र यस्तै। मैले ClickHouse को बारे मा अधिक राम्रो समीक्षा देखे।

Prometheus सर्भर मोडेल मा काम गर्दछ खींचो: ऊ हामीले उसलाई दिएका अन्तिम बिन्दुहरूमा मेट्रिक्सको लागि जान्छ। तिनीहरूले भने: "एपीआई सर्भरमा जानुहोस्", र उहाँ त्यहाँ प्रत्येक n-th सेकेन्डमा जानुहुन्छ र मेट्रिक्स लिनुहुन्छ।

छोटो जीवनकाल (काम वा क्रोन काम) भएका वस्तुहरूका लागि जुन स्क्र्यापिङ अवधिहरू बीच देखा पर्न सक्छ, त्यहाँ पुशगेटवे कम्पोनेन्ट छ। छोटो अवधिका वस्तुहरूबाट मेट्रिकहरू यसमा धकेलिन्छन्: काम बढेको छ, कार्य प्रदर्शन गरेको छ, पुशगेटवेमा मेट्रिक्स पठाइएको छ र पूरा भयो। केही समय पछि, प्रोमेथियस आफ्नै गतिमा तल आउनेछन् र पुशगेटवेबाट यी मेट्रिकहरू उठाउनेछन्।

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

र अन्तमा, म तपाईंलाई प्रोमेथियस किलर सुविधाको बारेमा बताउनेछु - खोज्दै। Prometheus संग काम गर्दा, तपाईं निगरानी को लागी वस्तुहरु को विशिष्ट ठेगाना निर्दिष्ट गर्न आवश्यक छैन, यो तिनीहरूको प्रकार सेट गर्न पर्याप्त छ। त्यो हो, तपाईले "यहाँ आईपी ठेगाना छ, यहाँ पोर्ट - मोनिटर छ" लेख्न आवश्यक छैन, बरु, तपाईले यी वस्तुहरू फेला पार्ने सिद्धान्तहरू द्वारा निर्धारण गर्न आवश्यक छ (लक्ष्य - लक्ष्यहरू)। प्रोमेथियस आफैं, कुन वस्तुहरू हाल सक्रिय छन् भन्ने आधारमा, आवश्यक वस्तुहरू तान्छन् र तिनीहरूलाई निगरानीमा थप्छन्।

यो दृष्टिकोण Kubernetes संरचना संग राम्रोसँग मिल्छ, जहाँ सबै कुरा पनि तैरिन्छ: आज त्यहाँ 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. फायरिङ तेस्रो स्थिति हो जब अलर्ट बत्ती र सन्देशहरू पठाउँछ।

स्थिति मेनुमा तपाईंले Prometheus के हो भन्ने बारे जानकारीमा पहुँच पाउनुहुनेछ। त्यहाँ लक्ष्य (लक्ष्य) मा एक संक्रमण पनि छ, जुन हामीले माथि कुरा गर्यौं।

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

Grafana संग एकीकरण

प्रोमेथियस वेब इन्टरफेसमा, तपाईंले सुन्दर र बुझ्न सकिने ग्राफहरू फेला पार्नुहुनेछैन जसबाट तपाईंले क्लस्टरको अवस्थाको बारेमा निष्कर्ष निकाल्न सक्नुहुन्छ। तिनीहरूलाई निर्माण गर्न, Prometheus Grafana संग एकीकृत छ। हामीले त्यस्ता ड्यासबोर्डहरू पाउँछौं।

Prometheus र Grafana एकीकरण सेटअप गर्न गाह्रो छैन, तपाइँ कागजातमा निर्देशनहरू फेला पार्न सक्नुहुन्छ: प्रोमेथियसका लागि ग्राफाना समर्थनखैर, म यो संग समाप्त गर्छु।

निम्न लेखहरूमा, हामी अनुगमनको विषयलाई जारी राख्नेछौं: हामी Grafana Loki र वैकल्पिक उपकरणहरू प्रयोग गरेर लगहरू सङ्कलन र विश्लेषण गर्ने बारे कुरा गर्नेछौं।

लेखक: मार्सेल इब्राभ, प्रमाणित कुबर्नेट्स प्रशासक, कम्पनीमा अभ्यास इन्जिनियर साउथब्रिज, वक्ता र पाठ्यक्रम विकासकर्ता Slurm।

स्रोत: www.habr.com