थानोस - स्केलेबल प्रोमेथियस

लेखको अनुवाद पाठ्यक्रमका विद्यार्थीहरूको लागि विशेष गरी तयार गरिएको थियो "DevOps अभ्यास र उपकरणहरू".

Fabian Reinartz एक सफ्टवेयर विकासकर्ता, गो फ्यानेटिक, र समस्या समाधानकर्ता हो। उहाँ एक प्रोमेथियस संरक्षक र कुबर्नेट्स SIG इन्स्ट्रुमेन्टेसनको सह-संस्थापक पनि हुनुहुन्छ। विगतमा, उहाँ साउन्डक्लाउडमा उत्पादन इन्जिनियर हुनुहुन्थ्यो र CoreOS मा निगरानी टोलीको नेतृत्व गर्नुभयो। हाल Google मा काम गर्नुहुन्छ।

Bartek Plotka - असम्भव मा पूर्वाधार इन्जिनियर। उहाँ नयाँ प्रविधिहरू र वितरण प्रणालीको समस्याहरूमा रुचि राख्नुहुन्छ। उहाँसँग Intel मा निम्न-स्तरको प्रोग्रामिङ अनुभव छ, Mesos मा योगदानकर्ता अनुभव, र Improbable मा विश्व-स्तरीय SRE उत्पादन अनुभव छ। Microservices को संसार सुधार गर्न समर्पित। उनको तीन प्रेम: गोलाङ, खुला स्रोत र भलिबल।

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

Prometheus को सादगी र विश्वसनीयता यसको मुख्य फाइदाहरु मध्ये एक हो। यद्यपि, एक पटक हामीले एक निश्चित मापदण्ड पार गरेपछि, हामीले धेरै कमजोरीहरू सामना गर्यौं। यी समस्याहरू समाधान गर्न हामीले विकास गरेका छौं Thanos अवस्थित प्रोमिथियस क्लस्टरहरूलाई असीमित ऐतिहासिक डाटा भण्डारणको साथ एकल निगरानी प्रणालीमा निर्बाध रूपमा रूपान्तरण गर्न Improbable द्वारा सिर्जना गरिएको खुला स्रोत परियोजना हो। Thanos Github मा उपलब्ध छ यहाँ.

Improbable बाट नवीनतम समाचार संग अद्यावधिक रहनुहोस्।

Thanos संग हाम्रो लक्ष्य

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

यी मुद्दाहरूलाई सम्बोधन गर्न, हामीले Thanos सिर्जना गर्यौं। निम्न खण्डहरूले हामीले यी मुद्दाहरूमा कसरी पुग्यौं र हाम्रा लक्ष्यहरूलाई व्याख्या गर्छौं।

धेरै प्रोमेथियस उदाहरणहरूबाट डाटा क्वेरी गर्दै (ग्लोबल क्वेरी)

प्रोमेथियसले शेर्डिङको लागि कार्यात्मक दृष्टिकोण प्रदान गर्दछ। एकल प्रोमेथियस सर्भरले पनि लगभग सबै प्रयोग केसहरूमा तेर्सो शेर्डिङको जटिलताबाट प्रयोगकर्ताहरूलाई मुक्त गर्न पर्याप्त स्केलेबिलिटी प्रदान गर्दछ।

जबकि यो एक उत्कृष्ट परिनियोजन मोडेल हो, यो प्राय: एकल एपीआई वा UI मार्फत विभिन्न प्रोमिथियस सर्भरहरूमा डाटा पहुँच गर्न आवश्यक छ - एक विश्वव्यापी दृश्य। निस्सन्देह, एक Grafana प्यानलमा धेरै प्रश्नहरू प्रदर्शन गर्न सम्भव छ, तर प्रत्येक क्वेरी केवल एक प्रोमेथियस सर्भरमा कार्यान्वयन गर्न सकिन्छ। अर्कोतर्फ, थानोसको साथ तपाईले धेरै प्रोमेथियस सर्भरहरूबाट डेटा क्वेरी गर्न र जम्मा गर्न सक्नुहुन्छ किनभने तिनीहरू सबै एकल अन्त्य बिन्दुबाट पहुँचयोग्य छन्।

पहिले, असम्भवमा विश्वव्यापी दृश्य प्राप्त गर्न, हामीले हाम्रा प्रोमेथियस उदाहरणहरूलाई बहु-स्तरमा व्यवस्थित गर्यौं। श्रेणीबद्ध महासंघ। यसको मतलब एउटा प्रोमेथियस मेटा सर्भर सिर्जना गर्नु हो जसले प्रत्येक पात सर्भरबाट केही मेट्रिकहरू सङ्कलन गर्दछ।

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

उच्च-उपलब्धता (HA) प्रोमेथियस सर्भरहरूमा सङ्कलन गरिएको डाटाको एक एकीकृत दृश्य यससँग नजिकको रूपमा सम्बन्धित छ। प्रोमेथियसको HA मोडेलले स्वतन्त्र रूपमा दुई पटक डाटा सङ्कलन गर्दछ, जुन यति सरल छ कि यो सरल हुन सक्दैन। यद्यपि, दुबै स्ट्रिमहरूको संयुक्त र डुप्लिकेट दृश्य प्रयोग गर्दा धेरै सुविधाजनक हुनेछ।

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

ऐतिहासिक डाटाको भरपर्दो भण्डारण

सस्तो, छिटो, दीर्घकालीन मेट्रिक्स भण्डारण हाम्रो सपना हो (धेरै प्रोमेथियस प्रयोगकर्ताहरू द्वारा साझा गरिएको)। असम्भव मा, हामी मेट्रिक्स अवधारण अवधि नौ दिनमा कन्फिगर गर्न बाध्य भयौं (प्रोमेथियस 1.8 को लागी)। यसले हामी कति टाढा हेर्न सक्छौं भन्ने स्पष्ट सीमाहरू थप्छ।

Prometheus 2.0 यस सन्दर्भमा सुधारिएको छ, किनकि समय श्रृंखलाको संख्याले सर्भरको समग्र प्रदर्शनलाई असर गर्दैन (हेर्नुहोस्। प्रोमेथियस २ को बारेमा कुबेकोन मुख्य टिप्पणी)। यद्यपि, प्रोमेथियसले स्थानीय डिस्कमा डाटा भण्डारण गर्दछ। यद्यपि उच्च-दक्षता डेटा सङ्कुचनले स्थानीय SSD उपयोगलाई उल्लेखनीय रूपमा कम गर्न सक्छ, त्यहाँ अन्ततः अझै पनि ऐतिहासिक डेटा भण्डारण गर्न सकिने मात्राको सीमा छ।

थप रूपमा, Improbable मा हामी विश्वसनीयता, सरलता र लागतको ख्याल राख्छौं। ठूला स्थानीय डिस्कहरू सञ्चालन गर्न र ब्याकअप गर्न गाह्रो हुन्छ। तिनीहरूले अधिक लागत र अधिक ब्याकअप उपकरणहरू आवश्यक, अनावश्यक जटिलताको परिणामस्वरूप।

डाउनसम्पलिंग

हामीले ऐतिहासिक डेटासँग काम गर्न थालेपछि, हामीले हप्ता, महिना र वर्षको डेटासँग काम गर्दा प्रश्नहरूलाई ढिलो र ढिलो बनाउने big-O सँग आधारभूत कठिनाइहरू छन् भनी हामीले महसुस गर्यौं।

यो समस्या को मानक समाधान हुनेछ डाउनसम्पलिंग (downsampling) - सिग्नल नमूना आवृत्ति कम गर्दै। डाउनसम्पलिंगको साथ, हामी ठूलो समय दायरामा "तल मापन" गर्न सक्छौं र प्रश्नहरू उत्तरदायी राख्दै नमूनाहरूको समान संख्या कायम राख्न सक्छौं।

पुरानो डाटा डाउनस्याम्पलिंग कुनै पनि दीर्घकालीन भण्डारण समाधानको अपरिहार्य आवश्यकता हो र यो भेनिला प्रोमेथियसको दायरा बाहिर छ।

अतिरिक्त लक्ष्यहरू

थानोस परियोजनाको मूल लक्ष्यहरू मध्ये एक कुनै पनि अवस्थित प्रोमेथियस स्थापनाहरूसँग निर्बाध रूपमा एकीकृत गर्नु थियो। दोस्रो लक्ष्य प्रवेशको लागि न्यूनतम अवरोधहरूको साथ सञ्चालनको सजिलो थियो। कुनै पनि निर्भरताहरू दुवै साना र ठूला प्रयोगकर्ताहरूको लागि सजिलै सन्तुष्ट हुनुपर्दछ, जसको अर्थ कम आधार लागत पनि हो।

थानोस वास्तुकला

अघिल्लो खण्डमा हाम्रा लक्ष्यहरू सूचीबद्ध गरेपछि, तिनीहरू मार्फत काम गरौं र थानोसले यी समस्याहरूलाई कसरी समाधान गर्छ हेरौं।

विश्वव्यापी दृश्य

अवस्थित प्रोमिथियस उदाहरणहरूको शीर्षमा विश्वव्यापी दृश्य प्राप्त गर्न, हामीले सबै सर्भरहरूमा एकल अनुरोध प्रविष्टि बिन्दु लिङ्क गर्न आवश्यक छ। यो वास्तवमा Thanos कम्पोनेन्टले गर्छ। Sidecar। यो प्रत्येक प्रोमिथियस सर्भरको छेउमा तैनाथ गरिएको छ र प्रोक्सीको रूपमा कार्य गर्दछ, gRPC स्टोर API मार्फत स्थानीय प्रोमिथियस डेटा सेवा गर्दै, ट्याग र समय दायराद्वारा समय श्रृंखला डेटा पुन: प्राप्त गर्न अनुमति दिँदै।

अर्को छेउमा स्केल-आउट, स्टेटलेस क्वेरियर कम्पोनेन्ट हो, जसले मानक प्रोमेथियस HTTP API मार्फत PromQL प्रश्नहरूको जवाफ दिनु भन्दा थोरै गर्छ। Querier, Sidecar र अन्य Thanos कम्पोनेन्टहरू मार्फत सञ्चार गर्छन् गपशप प्रोटोकल.

1. Querier, अनुरोध प्राप्त गरेपछि, सम्बन्धित स्टोर API सर्भरमा जडान हुन्छ, त्यो हो, हाम्रो Sidecars मा र सम्बन्धित Prometheus सर्भरहरूबाट समय श्रृंखला डेटा प्राप्त गर्दछ।
2. त्यस पछि, यसले प्रतिक्रियाहरू संयोजन गर्दछ र तिनीहरूमा PromQL क्वेरी कार्यान्वयन गर्दछ। Querier ले Prometheus HA सर्भरहरूबाट विच्छेदन डेटा र डुप्लिकेट डेटा दुवै मर्ज गर्न सक्छ।

यसले हाम्रो पज्जलको एउटा प्रमुख टुक्रा हल गर्छ - एकल दृश्यमा पृथक प्रोमेथियस सर्भरहरूबाट डेटा संयोजन गर्दै। वास्तवमा, Thanos मात्र यो सुविधाको लागि प्रयोग गर्न सकिन्छ। अवस्थित प्रोमेथियस सर्भरहरूमा कुनै परिवर्तनहरू गर्न आवश्यक छैन!

असीमित शेल्फ जीवन!

यद्यपि, ढिलो वा चाँडो हामी सामान्य प्रोमेथियस अवधारण समय भन्दा बाहिर डाटा भण्डारण गर्न चाहन्छौं। हामीले ऐतिहासिक डेटा भण्डारण गर्न वस्तु भण्डारण रोज्यौं। यो कुनै पनि क्लाउडका साथै अन-प्रिमाइसेस डाटा केन्द्रहरूमा व्यापक रूपमा उपलब्ध छ र धेरै लागत प्रभावकारी छ। थप रूपमा, लगभग कुनै पनि वस्तु भण्डारण प्रसिद्ध S3 API मार्फत उपलब्ध छ।

प्रोमेथियसले लगभग हरेक दुई घण्टामा RAM बाट डिस्कमा डाटा लेख्छन्। भण्डारण गरिएको डाटा ब्लकमा निश्चित समयको लागि सबै डाटा समावेश हुन्छ र अपरिवर्तनीय हुन्छ। यो धेरै सुविधाजनक छ किनकि थानोस साइडकारले प्रोमेथियस डाटा डाइरेक्टरीमा मात्र हेर्न सक्छ र नयाँ ब्लकहरू उपलब्ध भएपछि, तिनीहरूलाई वस्तु भण्डारण बाल्टिनहरूमा लोड गर्नुहोस्।

डिस्कमा लेखेपछि तुरुन्तै वस्तु भण्डारणमा लोड गर्नाले तपाईंलाई स्क्रैपर (प्रोमेथियस र थानोस साइडकार) को सरलता कायम राख्न अनुमति दिन्छ। जसले समर्थन, लागत र प्रणाली डिजाइनलाई सरल बनाउँछ।

तपाईं देख्न सक्नुहुन्छ, डाटा ब्याकअप धेरै सरल छ। तर वस्तु भण्डारणमा डाटा क्वेरी गर्ने बारे के हो?

थानोस स्टोर कम्पोनेन्टले वस्तु भण्डारणबाट डाटा पुन: प्राप्त गर्न प्रोक्सीको रूपमा कार्य गर्दछ। Thanos Sidecar जस्तै, यसले गसिप क्लस्टरमा भाग लिन्छ र स्टोर API लागू गर्दछ। यस तरिकाले, अवस्थित Querier ले यसलाई Sidecar जस्तै व्यवहार गर्न सक्छ, समय श्रृंखला डेटाको अर्को स्रोतको रूपमा - कुनै विशेष कन्फिगरेसन आवश्यक पर्दैन।

समय श्रृंखला डेटा ब्लकहरू धेरै ठूला फाइलहरू हुन्छन्। तिनीहरूलाई मागमा लोड गर्न एकदमै असक्षम हुनेछ, र तिनीहरूलाई स्थानीय रूपमा क्यास गर्न मेमोरी र डिस्क ठाउँको ठूलो मात्रा चाहिन्छ।

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

माथिको रेखाचित्रमा देखाइएझैं, थानोस क्वेरियरले प्रोमिथियस भण्डारण ढाँचाको लाभ उठाएर र सम्बन्धित डाटालाई छेउमा राखेर वस्तु भण्डारण डाटाको प्रति क्वेरी लागतलाई उल्लेखनीय रूपमा घटाउँछ। यो दृष्टिकोण प्रयोग गरेर, हामी धेरै एकल अनुरोधहरूलाई न्यूनतम संख्यामा बल्क सञ्चालनहरूमा जोड्न सक्छौं।

कम्प्याक्शन र डाउनसम्पलिंग

एक पटक समय श्रृंखला डेटाको नयाँ ब्लक वस्तु भण्डारणमा सफलतापूर्वक लोड भएपछि, हामी यसलाई "ऐतिहासिक" डेटाको रूपमा व्यवहार गर्छौं, जुन स्टोर गेटवे मार्फत तुरुन्तै उपलब्ध हुन्छ।

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

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

डाटालाई डाउनसम्पल गर्न, कम्प्याक्टरले लगातार पाँच मिनेट र एक घण्टाको रिजोलुसनमा डाटा जम्मा गर्छ। TSDB XOR कम्प्रेसन प्रयोग गरी एन्कोड गरिएको प्रत्येक कच्चा भागको लागि, विभिन्न प्रकारका समग्र डेटा भण्डारण गरिन्छ, जस्तै न्यूनतम, अधिकतम वा एक ब्लकको लागि योग। यसले Querier लाई दिइएको PromQL क्वेरीको लागि उपयुक्त भएको समुच्चय स्वतः चयन गर्न अनुमति दिन्छ।

कम सटीक डेटा प्रयोग गर्न प्रयोगकर्ताको लागि कुनै विशेष कन्फिगरेसन आवश्यक छैन। प्रयोगकर्ताले जुम इन र आउट गर्दा Querier स्वचालित रूपमा विभिन्न रिजोल्युसन र कच्चा डाटा बीच स्विच गर्दछ। यदि चाहियो भने, प्रयोगकर्ताले अनुरोधमा "चरण" प्यारामिटर मार्फत यसलाई सीधा नियन्त्रण गर्न सक्छ।

एक जीबी भण्डारणको लागत कम भएकोले पूर्वनिर्धारित रूपमा थानोसले कच्चा डाटा, पाँच मिनेट र एक घण्टाको रिजोल्युसन डाटा भण्डारण गर्छ। मूल डाटा मेटाउन आवश्यक छैन।

रेकर्डिङ नियमहरू

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

• ग्लोबल अलर्ट र नियम (उदाहरणका लागि, सेवाले तीन मध्ये दुई भन्दा बढी क्लस्टरहरूमा काम नगर्दा अलर्ट)।
• स्थानीय भण्डारण बाहिर डेटा को लागी नियम।
• सबै नियम र अलर्टहरू एकै ठाउँमा भण्डारण गर्ने इच्छा।

यी सबै केसहरूको लागि, Thanos मा Ruler भनिने छुट्टै कम्पोनेन्ट समावेश गर्दछ, जसले Thanos Querys मार्फत नियम र सतर्कताको गणना गर्दछ। एक प्रसिद्ध StoreAPI प्रदान गरेर, क्वेरी नोडले भर्खरै गणना गरिएको मेट्रिक्स पहुँच गर्न सक्छ। पछि ती वस्तु भण्डारणमा पनि भण्डारण गरिन्छ र स्टोर गेटवे मार्फत उपलब्ध गराइन्छ।

थानोसको शक्ति

थानोस तपाईंको आवश्यकता अनुरूप अनुकूलित गर्न पर्याप्त लचिलो छ। यो विशेष गरी उपयोगी हुन्छ जब सादा प्रोमेथियसबाट माइग्रेट हुन्छ। थानोस कम्पोनेन्टहरूको बारेमा हामीले सिकेका कुराहरूलाई द्रुत उदाहरणको साथ द्रुत रूपमा पुन: क्याप गरौं। यहाँ "असीमित मेट्रिक्स भण्डारण" को संसारमा तपाइँको भेनिला प्रोमेथियस कसरी लैजाने भन्ने छ:

1. तपाईंको प्रोमेथियस सर्भरहरूमा थानोस साइडकार थप्नुहोस् - उदाहरणका लागि, कुबेरनेट पोडमा साइडकार कन्टेनर।
2. डाटा हेर्न सक्षम हुन धेरै Thanos Querier प्रतिकृतिहरू प्रयोग गर्नुहोस्। यस चरणमा स्क्रैपर र क्वेरियर बीच गपशप सेट अप गर्न सजिलो छ। अवयवहरूको अन्तरक्रिया जाँच गर्न, 'thanos_cluster_members' मेट्रिक प्रयोग गर्नुहोस्।

सम्भावित प्रोमेथियस HA प्रतिकृतिहरूबाट विश्वव्यापी दृश्य र सिमलेस डाटा डुप्लिकेशन प्रदान गर्न यी दुई चरणहरू मात्र पर्याप्त छन्! केवल आफ्नो ड्यासबोर्डहरू Querier HTTP अन्त्य बिन्दुमा जडान गर्नुहोस् वा सिधै Thanos UI प्रयोग गर्नुहोस्।

यद्यपि, यदि तपाईंलाई मेट्रिक्स ब्याकअप र दीर्घकालीन भण्डारण चाहिन्छ भने, तपाईंले थप तीन चरणहरू पूरा गर्नुपर्नेछ:

1. AWS S3 वा GCS बाल्टी सिर्जना गर्नुहोस्। यी बकेटहरूमा डाटा प्रतिलिपि गर्न Sidecar कन्फिगर गर्नुहोस्। स्थानीय डाटा भण्डारण अब न्यूनतम गर्न सकिन्छ।
2. स्टोर गेटवे डिप्लोय गर्नुहोस् र यसलाई तपाईंको अवस्थित गसिप क्लस्टरमा जडान गर्नुहोस्। अब तपाईं जगेडा डाटा क्वेरी गर्न सक्नुहुन्छ!
3. कम्प्याक्शन र डाउनसम्पलिंग प्रयोग गरेर लामो समयसम्म क्वेरी दक्षता सुधार गर्न कम्प्याक्टर प्रयोग गर्नुहोस्।

यदि तपाईं थप जान्न चाहनुहुन्छ भने, हाम्रो एक नजर लिन नहिचकिचाउनुहोस् kubernetes प्रकट उदाहरणहरू и सुरु गर्दै!

केवल पाँच चरणहरूमा, हामीले प्रोमेथियसलाई विश्वव्यापी दृश्य, असीमित भण्डारण समय र मेट्रिक्सको सम्भावित उच्च उपलब्धताको साथ एक विश्वसनीय निगरानी प्रणालीमा परिणत गर्यौं।

पुल अनुरोध: हामीलाई तपाई चाहिन्छ!

Thanos सुरुदेखि नै खुला स्रोत परियोजना हो। प्रोमेथियससँग सिमलेस एकीकरण र थानोसको मात्र एक अंश प्रयोग गर्ने क्षमताले यसलाई तपाईंको निगरानी प्रणाली सहज रूपमा स्केल गर्नको लागि उत्कृष्ट विकल्प बनाउँछ।

हामी सधैं GitHub पुल अनुरोध र मुद्दाहरूलाई स्वागत गर्दछौं। यस बीचमा, Github Issues वा slack मार्फत हामीलाई सम्पर्क गर्न नहिचकिचाउनुहोस् असम्भव-eng #thanosयदि तपाइँसँग प्रश्न वा प्रतिक्रिया छ, वा यसलाई प्रयोग गरेर तपाइँको अनुभव साझा गर्न चाहनुहुन्छ भने! यदि तपाईलाई हामीले Improbable मा गर्ने काम मनपर्छ भने, हामीलाई सम्पर्क गर्न नहिचकिचाउनुहोस् - हामीसँग सधैं रिक्त पदहरू छन्!

पाठ्यक्रम बारे थप जान्नुहोस्।

स्रोत: www.habr.com