🥇प्रोमेथियसको लागि डेटा भण्डारण छनौट गर्दै: थानोस बनाम भिक्टोरियामेट्रिक्स

नमस्ते सबै। तल ट्रान्सक्रिप्ट छ बिग निगरानी बैठक 4 बाट रिपोर्ट.

Prometheus - विभिन्न प्रणाली र सेवाहरूको लागि एक निगरानी प्रणाली, जसको मद्दतले प्रणाली प्रशासकहरूले प्रणालीहरूको हालको प्यारामिटरहरूको बारेमा जानकारी सङ्कलन गर्न सक्छन् र प्रणालीहरूको सञ्चालनमा विचलनहरू बारे सूचनाहरू प्राप्त गर्न अलर्टहरू सेट अप गर्न सक्छन्।

प्रतिवेदनमा तुलना समावेश हुनेछ Thanos и भिक्टोरियामेट्रिक्स - प्रोमेथियस मेट्रिक्स को दीर्घकालीन भण्डारण को लागी परियोजनाहरु।

प्रोमेथियसको लागि डाटा भण्डारण छनौट गर्दै: थानोस बनाम भिक्टोरियामेट्रिक्स

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

प्रोमेथियस सीमाहरू:

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

यी समस्या/चुनौतीहरूको समाधान?

समाधानहरू हुन्:

यी सबै समाधानहरू प्रोमेथियसद्वारा सङ्कलन गरिएको डाटाको रिमोट भण्डारणका लागि हुन्। तिनीहरूले अघिल्लो स्लाइडबाट टाढाको भण्डारण समस्यालाई विभिन्न तरिकामा समाधान गर्छन्। यस प्रस्तुतिमा म पहिलो दुई समाधानहरूको बारेमा मात्र कुरा गर्नेछु: Thanos и भिक्टोरियामेट्रिक्स.

को बारेमा पहिलो पटक जानकारी Thanos द्वारा देखा पर्‍यो यो लिङ्क। त्यहाँ वास्तुकला वर्णन गरिएको छ Thanos र यो कसरी काम गर्दछ।

थानोसले प्रोमेथियसले स्थानीय डिस्कमा बचत गरेको डाटा लिन्छ र यसलाई S3 मा प्रतिलिपि गर्दछ, जीसीएस वा अर्को वस्तु भण्डारणमा।

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

Thanos PromQL र समर्थन गर्दछ प्रोमेथियस क्वेरी API.

Thanos डाटा भण्डारण गर्न Prometheus कोड प्रयोग गर्दछ।

थानोस प्रोमेथियस जस्तै विकासकर्ताहरू द्वारा विकसित गरिएको हो।

बारेमा भिक्टोरियामेट्रिक्स। यहाँ लिङ्क, जहाँ हामीले पहिलो कुरा गर्यौं भिक्टोरियामेट्रिक्स.

VictoriaMetrics ले धेरै prometheus बाट डाटा प्राप्त गर्दछ रिमोट लेखन API प्रोमेथियस द्वारा समर्थित प्रोटोकल।

VictoriaMetrics ले विश्वव्यापी क्वेरी दृश्य प्रदान गर्दछ, किनकि धेरै Prometheus उदाहरणहरूले एक VictoriaMetrics मा डेटा लेख्न सक्छ। तदनुसार, तपाइँ यी सबै डाटामा प्रश्नहरू गर्न सक्नुहुन्छ।

VictoriaMetrics ले पनि समर्थन गर्दछ, जस्तै Thanos, PromQL र Prometheus querying API।

Thanos को विपरीत, VictoriaMetrics स्रोत कोड स्क्र्याच देखि लेखिएको छ र गति र स्रोत खपत को लागी अनुकूलित छ।

VictoriaMetrics, Thanos को विपरीत, ठाडो र तेर्सो दुवै मापन। खानुहोस् एकल-नोड संस्करण, जुन ठाडो मापन गर्दछ। तपाईं एक प्रोसेसर र 1 GB मेमोरीबाट सुरु गर्न सक्नुहुन्छ र बिस्तारै सयौं प्रोसेसर र 1 TB मेमोरीमा बढ्न सक्नुहुन्छ। VictoriaMetrics ले यी सबै स्रोतहरू प्रयोग गर्न सक्छ। यसको कार्यसम्पादन १-कोर प्रणालीको तुलनामा करिब १०० गुणाले बढ्नेछ।

थानोसको इतिहास नोभेम्बर 2017 मा सुरु भयो, जब पहिलो सार्वजनिक कमिट देखा पर्‍यो। यस अघि, थानोस आन्तरिक रूपमा विकसित गरिएको थियो improbable.io.

जुन 2019 मा त्यहाँ 0.5.0 ल्यान्डमार्क रिलीज भएको थियो, जसमा हटाइयो गपशप प्रोटोकल। उनले राम्रो प्रदर्शन नगरेका कारण उनलाई थानोसबाट हटाइयो । प्रायः थानोस क्लस्टरले सही रूपमा काम गरेन, गपशप प्रोटोकलको कारणले नोडहरू गलत रूपमा जोडिएका छन्। त्यसैले हामीले उनलाई त्यहाँबाट हटाउने निर्णय गर्‍यौं। मलाई लाग्छ यो सही निर्णय हो।

त्यही जुन २०१९ मा उनीहरूले आवेदन नम्बर पठाए 256 в क्लाउड नेटिभ कम्प्युटिंग फाउन्डेशन.

र केहि महिना पछि थानोस मा स्वीकार गरियो क्लाउड नेटिभ कम्प्युटिंग फाउन्डेशन, जसमा Prometheus, Kubernetes र अन्य लोकप्रिय परियोजनाहरू समावेश छन्।

जनवरी 2018 मा, VictoriaMetrics को विकास सुरु भयो।

सेप्टेम्बर 2018 मा, मैले सार्वजनिक रूपमा पहिलो पटक VictoriaMetrics उल्लेख गरें।

डिसेम्बर 2018 मा, एकल-नोड संस्करण प्रकाशित भएको थियो।

मई 2019 मा प्रकाशित भएका थिए दुबै एकल-नोड र क्लस्टर संस्करणहरूको स्रोत।

जुन 2019 मा, थानोस जस्तै हामीले CNCF फाउन्डेसनमा नम्बर अन्तर्गत आवेदन पेस गर्‍यौं 255। हामीले थानोसले आवेदन दिनुअघि नै आवेदन दियौं।

तर, दुर्भाग्यवश, हामीलाई अझै पनि त्यहाँ स्वीकार गरिएको छैन। सामुदायिक सहयोग आवश्यक छ।

थानोस र भिक्टोरियामेट्रिक्सको वास्तुकला देखाउने सबैभन्दा महत्त्वपूर्ण स्लाइडहरू हेरौं।

थानोसबाट सुरु गरौं। पहेंलो कम्पोनेन्टहरू प्रोमेथियस कम्पोनेन्टहरू हुन्। अरू सबै थानोस कम्पोनेन्टहरू हुन्। सबैभन्दा महत्त्वपूर्ण घटकको साथ सुरु गरौं। थानोस साइडकार एक कम्पोनेन्ट हो जुन प्रत्येक प्रोमेथियसको छेउमा स्थापित हुन्छ। यसले स्थानीय भण्डारणबाट प्रोमिथियस डाटालाई S3 वा अर्को वस्तु भण्डारणमा लोड गर्दछ।

थानोस स्टोर गेटवे नामक कम्पोनेन्ट पनि छ, जसले थानोस क्वेरीबाट आउने अनुरोधहरूमा वस्तु भण्डारणबाट यो डाटा पढ्न सक्छ। Thanos Query PromQL र Prometheus API लागू गर्दछ। अर्थात्, बाहिरबाट यो प्रोमेथियस जस्तो देखिन्छ। PromQL प्रश्नहरू प्राप्त गर्दछ, तिनीहरूलाई थानोस स्टोर गेटवेमा पठाउँदछ, थानोस स्टोर गेटवेले वस्तु भण्डारणबाट आवश्यक डाटा पुन: प्राप्त गर्दछ, यसलाई फिर्ता पठाउँदछ।

तर हामीले Thanos Sidecar कार्यान्वयनको सुविधाको कारणले अन्तिम दुई घण्टा बिना वस्तु भण्डारणमा डेटा भण्डारण गर्छौं, जसले अन्तिम दुई घण्टा वस्तु भण्डारण S3 मा अपलोड गर्न सक्दैन, किनभने Prometheus ले स्थानीय भण्डारणमा यी दुई घण्टाका लागि फाइलहरू सिर्जना गरेको छैन।

तपाईंले यो वरिपरि प्राप्त गर्ने निर्णय कसरी गर्नुभयो? Thanos Query, Thanos Store गेटवेमा अनुरोधहरूको अतिरिक्त, प्रत्येक Thanos Sidecar लाई समानान्तर अनुरोधहरू पठाउँदछ, जुन Prometheus को छेउमा अवस्थित छ।

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

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

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

यो थानोसको सरल योजना हो।

अब यसलाई VictoriaMetrics योजनासँग तुलना गरौं।

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

क्लस्टर संस्करण थप जटिल छ। यसको भित्र तीन फरक कम्पोनेन्टहरू छन्: vmselect, vminsert र vmstorage। तिनीहरूको नामबाट यो स्पष्ट हुनुपर्छ कि तिनीहरूले के गर्छन्। Insert कम्पोनेन्टले विभिन्न ढाँचाहरूमा डाटा स्वीकार गर्छ: Prometheus remote write API, Influx line protocol, Graphite प्रोटोकल र OpenTSDB प्रोटोकलबाट। सम्मिलित कम्पोनेन्टले तिनीहरूलाई स्वीकार गर्दछ, तिनीहरूलाई पार्स गर्दछ र अवस्थित भण्डारण घटकहरू बीच वितरण गर्दछ, जहाँ डाटा पहिले नै भण्डार गरिएको छ। चयन घटक, बारीमा, PromQL प्रश्नहरू स्वीकार गर्दछ। उहाँले कार्यान्वयन गर्नुहुन्छ PromQL, साथै Prometheus querying API, र यसलाई Grafana वा अन्य Prometheus API क्लाइन्टहरूमा Prometheus को प्रतिस्थापनको रूपमा प्रयोग गर्न सकिन्छ। चयनले promql अनुरोध स्वीकार गर्दछ, यसलाई पार्स गर्दछ, भण्डारण नोडहरूबाट यो अनुरोध कार्यान्वयन गर्नको लागि आवश्यक डाटा पढ्छ, यो डाटा प्रशोधन गर्दछ र प्रतिक्रिया फर्काउँछ।

थानोस र भिक्टोरियामेट्रिक्स स्थापना गर्ने जटिलता तुलना गरौं।

थानोसबाट सुरु गरौं। तपाईंले Thanos सँग काम सुरु गर्नु अघि, तपाईंले वस्तु भण्डारणमा एउटा बाल्टी सिर्जना गर्न आवश्यक छ, जस्तै S3 वा GCS, ताकि Thanos Sidecar यसमा डेटा लेख्न सक्छ।

त्यसपछि प्रत्येक प्रोमेथियसको लागि तपाईंले थानोस साइडकार स्थापना गर्न आवश्यक छ। यो भन्दा पहिले, तपाईंले Prometheus मा डाटा कम्प्याक्शन असक्षम गर्न सम्झनु आवश्यक छ। डाटा कम्प्याक्शनले आवधिक रूपमा स्थानीय प्रोमेथियस भण्डारणमा डेटा कम्प्रेस गर्दछ ताकि स्रोत खपत कम हुन्छ।

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

तसर्थ, थानोसले ठूलो संख्यामा साना ब्लकहरूको ओभरहेड कम गर्न स्थानीय भण्डारणमा डाटा रिटेन्सन समयलाई 6-8 घण्टामा घटाउन सिफारिस गर्दछ।

एकपटक तपाईंले Thanos Sidecar स्थापना गरिसकेपछि, तपाईंले प्रत्येक वस्तु भण्डारण बाल्टिनको लागि दुईवटा कम्पोनेन्टहरू स्थापना गर्नुपर्छ। यी हुन् थानोस कम्प्याक्टर र थानोस स्टोर गेटवे।

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

यहाँ थोरै समस्या हुन सक्छ।

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

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

VictoriaMetrics मा सबै कुरा थोरै सरल छ। एकल-नोड संस्करणको लागि, तपाईंले केवल एउटा बाइनरी चलाउन आवश्यक छ र सबै काम गर्दछ।

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

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

थानोस र भिक्टोरियामेट्रिक्सको समर्थनलाई विचार गरौं।

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

थानोस कम्प्याक्टरले काम गर्न बन्द गर्न सक्छ Sidecar संग रेस। कम्प्याक्टरहरूले वस्तु भण्डारणबाट डाटा लिन्छन् र यसलाई डाटाको ठूला टुक्राहरूमा मर्ज गर्छन्। कम्प्याक्टरहरू Sidecars सँग सिङ्क्रोनाइज गरिएको छैन, निम्न हुन सक्छ: Sidecar ले ब्लक पूरा गर्न अझै समय पाएको छैन, कम्प्याक्टरले निर्णय गर्छ कि यो ब्लक पूर्ण रूपमा लेखिएको छ। कम्प्याक्टरले यसलाई पढ्न थाल्छ। यसले पूर्ण रूपमा ब्लक पढ्दैन र काम गर्न रोक्छ। विवरण हेर्नुहोस् यहाँ.

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

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

Thanos को विपरीत, VictoriaMetrics विरलै डाटा गुमाउँछ। Prometheus बाट VictoriaMetrics मा जडान अवरुद्ध भए पनि, यो कुनै समस्या छैन, किनकि Prometheus ले Write Ahead Log मा आगमन नयाँ डाटा रेकर्ड गर्न जारी राख्छ, जसको साइज २ घण्टा हो। यदि तपाईंले VictoriaMetrics मा आफ्नो जडान दुई घण्टा भित्र पुनर्स्थापित गर्नुभयो भने, तपाईंको डाटा हराउने छैन। प्रोमेथियस VictoriaMetrics जडान पुनर्स्थापना पछि डाटा थप्न सक्छ.

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

Kubernetes स्वचालित रूपमा क्लस्टर व्यवस्थापन गर्दछ, Thanos को विपरीत। VictoriaMetrics क्लस्टर कम्पोनेन्टहरू भन्दा फरक, सबै Thanos कम्पोनेन्टहरूलाई एउटा Kubernetes क्लस्टरमा राख्न गाह्रो छ।

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

VictoriaMetrics ले क्लस्टर विस्तार गर्न धेरै सजिलो बनाउँछ। केवल आवश्यक घटकहरू थप्नुहोस् र काम जारी राख्नुहोस्।

Thanos र VictoriaMetrics मा समस्याहरू बारे।

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

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

थानोसलाई तपाइँसँग भएको प्रोमेथियसको मात्रासँग अनिश्चित कालका लागि मापन गर्न विज्ञापन गरिएको छ। यो वास्तवमा सत्य होइन। सबै अनुरोधहरू क्वेरी कम्पोनेन्ट मार्फत जाने हुनाले, जसले एकै साथ सबै स्टोर गेटवे कम्पोनेन्टहरू र सबै साइडकार कम्पोनेन्टहरू पोल गर्नुपर्छ, त्यहाँबाट डाटा तान्नुहोस् र त्यसपछि यसलाई पूर्वप्रक्रिया गर्नुहोस्। जाहिर छ, अनुरोध गति सब भन्दा ढिलो कमजोर लिङ्क, ढिलो स्टोर गेटवे वा सबैभन्दा ढिलो Sidecar द्वारा सीमित छ।

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

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

VictoriaMetrics मा पनि कमजोरी छ। पहिलो समस्या भनेको VictoriaMetrics क्यासको लागि प्रयोग गरिएको RAM को मात्रा सीमित गर्ने विकल्प हो। पूर्वनिर्धारित रूपमा, यो VictoriaMetrics चलिरहेको मेसिनको RAM को 60% वा Kubernetes मा VictoriaMetrics पोडको RAM को 60% बराबर हुन्छ।

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

दोस्रो विकल्प। यो अवधारण अवधि हो - पूर्वनिर्धारित रूपमा 1 महिनामा सेट गरिएको अवधि। यो VictoriaMetrics डाटा भण्डारण गर्ने समयको लम्बाइ हो। यस अवधि पछि, VictoriaMetrics डाटा मेटाउँछ।

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

अनौठो विशेषताहरू हेरौं।

थानोससँग डाउनसम्पलिंग भनिने सुविधा छ: 5-मिनेट र घण्टाको अन्तराल, जुन प्राय: सही रूपमा काम गर्दैन। यदि तपाइँ गुगल गर्नुहुन्छ र github मा उनीहरूको मुद्दा हेर्नुहुन्छ, त्यहाँ यस डाउनसम्पलिंगसँग सम्बन्धित धेरै समस्याहरू छन्, कि यसले कहिलेकाँही सही रूपमा काम गर्दैन, वा प्रयोगकर्ताहरूले अपेक्षा गरे अनुसार काम गर्दैन।

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

थानोससँग एक अलर्ट कम्पोनेन्ट छ जुन थानोस योजनाबद्धमा थियो। तर उनलाई उत्पादनमा प्रयोगको लागि सिफारिस गरिएको छैन.

थानोसको फाइदा छ कि थानोस र प्रोमेथियसले समान कोड साझा गर्छन्। Thanos र Prometheus एउटै विकासकर्ता द्वारा विकसित गरिएको हो। Thanos वा Prometheus मा सुधार संग, अर्को पक्ष जित्छ।

VictoriaMetrics को मुख्य विशेषता MetricsQL हो। यी PromQL का लागि VictoriaMetrics विस्तारहरू हुन्, जुन मैले अघिल्लो ठूलो निगरानी मेटअपमा कुरा गरेको थिएँ।

VictoriaMetrics ले धेरै फरक प्रोटोकलहरू प्रयोग गरेर डाटा लोड गर्न समर्थन गर्दछ। VictoriaMetrics ले Prometheus बाट डाटा मात्र स्वीकार गर्न सक्दैन, तर Influx, OpenTSDB र Graphite प्रोटोकलहरू मार्फत पनि।

VictoriaMetrics डाटाले Thanos र Prometheus को तुलनामा धेरै कम ठाउँ लिन्छ।

यदि तपाइँ वास्तविक डाटा रेकर्ड गर्नुहुन्छ भने, प्रयोगकर्ताहरूले प्रोमेथियस र थानोसको तुलनामा डिस्कमा डाटाको आकारमा २-५ गुणा कमीको बारेमा कुरा गर्छन्।

VictoriaMetrics को अर्को फाइदा यो हो कि यो गति को लागी अनुकूलित छ।

पूर्वाधारको लागत हेरौं।

थानोसको एउटा फाइदा यो हो कि यसले वस्तु भण्डारणमा डाटा भण्डारण गर्दछ, जुन तुलनात्मक रूपमा सस्तो छ।

वस्तु भण्डारणमा डाटा भण्डारण गर्दा, तपाईंले डाटा लेखन र पढ्ने अपरेसनहरू ($ 10 प्रति मिलियन अपरेशनहरू) को लागि तिर्नु पर्छ। जब तपाइँ वस्तु भण्डारणमा डेटा लेख्नुहुन्छ, तपाइँ इन्टरनेटमा डाटा अपलोड गर्नको लागि तपाइँको होस्टिङ लागत तिर्नुहुन्छ यदि तपाइँको क्लस्टर AWS मा छैन भने, यो त्यहाँ निःशुल्क छ। जब तपाइँ डेटा पढ्नुहुन्छ, तपाइँ प्रति 10TB $ 230 र $ 1 बीच भुक्तान गर्नुहुन्छ। यदि तपाइँ थानोस क्लस्टरबाट बारम्बार ऐतिहासिक डेटा क्वेरी गर्नुहुन्छ भने यो महत्त्वपूर्ण हुन सक्छ।

थानोस क्लस्टरको लागि, तपाईंले कम्प्याक्ट, स्टोर गेटवे, धेरै मेमोरी चाहिने क्वेरी कम्पोनेन्टहरू, र ठूलो मात्रामा डाटाको लागि CPU को लागि सर्भरहरूको लागि भुक्तान गर्न आवश्यक छ।

VictoriaMetrics को निम्न खर्चहरू छन्। यदि तपाइँ GCE HDD ड्राइभहरूमा डेटा भण्डार गर्नुहुन्छ भने, त्यसपछि यो 40TB को लागि $ 1 मा आउँछ। VictoriaMetrics को लागि, साधारण HDD ड्राइभहरू पर्याप्त छैनन्, जसको लागत पाँच गुणा बढी छ। VictoriaMetrics HDD को लागी अनुकूलित छ।

VictoriaMetrics लाई कम्पोनेन्टहरूका लागि सर्भरहरू चाहिन्छ: या त एकल-नोड वा क्लस्टर गरिएका कम्पोनेन्टहरू, जसलाई थानोस कम्पोनेन्टहरू भन्दा कम CPU र RAM चाहिन्छ - र तदनुसार सस्तो हुनेछ।

कार्यान्वयनका उदाहरणहरू।

थानोसको Gitlab मा कार्यान्वयन उदाहरण छ। Gitlab पूर्ण रूपमा थानोसमा चल्छ। तर त्यहाँ सबै कुरा यति सहज छैन। यदि तपाईंले तिनीहरूलाई हेर्नुभयो भने मुद्दाहरू, तब तपाईले देख्न सक्नुहुन्छ कि तिनीहरूसँग निरन्तर केही छ Thanos संग परिचालन समस्याहरू: स्टोर गेटवे वा क्वेरी कम्पोनेन्टहरूको लागि पर्याप्त मेमोरी छैन। तिनीहरूले निरन्तर मेमोरीको मात्रा बढाउनु पर्छ।

यस कारण, यी समस्याहरू समाधान गर्न लागत बढ्छ।

दोस्रो कार्यान्वयन, जुन अझ सफल हुन सक्छ, असंभव कम्पनी हो, जसले थानोसको विकास गर्न थाल्यो। तिनीहरूले Thanos स्रोत कोड प्रकाशित गरे। Improbable एउटा कम्पनी हो जसले गेम इन्जिनहरू विकास गर्छ।

VictoriaMetrics सँग सार्वजनिक कार्यान्वयन उदाहरणहरू छन्:

wix.com वेबसाइट निर्माणकर्ता
एडिडासले VictoriaMetrics कार्यान्वयन गर्दैछ र अन्तिम PromCon 2019 मा एक प्रस्तुतीकरण पनि गरेको छ।
TrafficStars - विज्ञापन नेटवर्क
Seznam.cz एक लोकप्रिय चेक खोज इन्जिन हो।

र त्यसपछि त्यहाँ कुनै-नाम कम्पनीहरू थिए जुन म अहिले नाम दिन सक्दिन। उनीहरुले सहमति जनाएनन् ।

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

प्रोमेथियसको लागि डाटा भण्डारण छनौट गर्दै: थानोस बनाम भिक्टोरियामेट्रिक्स निष्कर्ष।