प्रोमिथियससाठी डेटा स्टोरेज निवडणे: थॅनोस वि व्हिक्टोरियामेट्रिक्स

सर्वांना नमस्कार. खाली उतारा आहे बिग मॉनिटरिंग मीटअप 4 कडून अहवाल.

Prometheus - विविध प्रणाली आणि सेवांसाठी एक मॉनिटरिंग सिस्टम, ज्याच्या मदतीने सिस्टम प्रशासक सिस्टमच्या सध्याच्या पॅरामीटर्सबद्दल माहिती गोळा करू शकतात आणि सिस्टमच्या ऑपरेशनमधील विचलनाबद्दल सूचना प्राप्त करण्यासाठी अलर्ट सेट करू शकतात.

अहवालात तुलना समाविष्ट असेल थानोस и व्हिक्टोरियामेट्रिक्स - प्रोमिथियस मेट्रिक्सच्या दीर्घकालीन संचयनासाठी प्रकल्प.

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

प्रोमिथियस मर्यादा:

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

या समस्या/ आव्हानांवर उपाय?

उपाय आहेत:

• थानोस
• व्हिक्टोरियामेट्रिक्स
• Uber M3
• कॉर्टेक्स

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

बद्दल प्रथमच माहिती थानोस द्वारे दिसू लागले हा दुवा. तेथे वास्तुकलेचे वर्णन केले आहे थानोस आणि ते कसे कार्य करते.

थॅनोस प्रॉमिथियसने स्थानिक डिस्कवर जतन केलेला डेटा घेतो आणि तो S3 वर कॉपी करतो. जीसीएस किंवा इतर ऑब्जेक्ट स्टोरेजमध्ये.

अशा प्रकारे थानोस जागतिक क्वेरी दृश्य प्रदान करते. तुम्ही एकाधिक प्रोमिथियस उदाहरणांमधून ऑब्जेक्ट स्टोरेजमध्ये संग्रहित डेटाची क्वेरी करू शकता.

थानोस PromQL ला समर्थन देते आणि प्रोमिथियस क्वेरीिंग API.

थानोस डेटा साठवण्यासाठी प्रोमिथियस कोड वापरतो.

थॅनोस हे प्रोमिथियस सारख्याच विकसकांनी विकसित केले आहे.

वर व्हिक्टोरियामेट्रिक्स. येथे ссылка, जिथे आम्ही प्रथम बोललो व्हिक्टोरियामेट्रिक्स.

व्हिक्टोरियामेट्रिक्सला अनेक प्रोमिथियसकडून डेटा प्राप्त होतो दूरस्थ लेखन API प्रोमिथियस द्वारे समर्थित प्रोटोकॉल.

VictoriaMetrics जागतिक क्वेरी दृश्य प्रदान करते, कारण एकाधिक Prometheus उदाहरणे एका VictoriaMetrics वर डेटा लिहू शकतात. त्यानुसार, तुम्ही या सर्व डेटावर क्वेरी करू शकता.

VictoriaMetrics देखील समर्थन करते, जसे की Thanos, PromQL आणि Prometheus querying API.

Thanos च्या विपरीत, VictoriaMetrics सोर्स कोड सुरवातीपासून लिहिलेला आहे आणि वेग आणि संसाधनाच्या वापरासाठी अनुकूल आहे.

व्हिक्टोरियामेट्रिक्स, थॅनोसच्या विपरीत, अनुलंब आणि क्षैतिज दोन्ही स्केल करतात. खा सिंगल-नोड आवृत्ती, जे अनुलंब स्केल करते. तुम्ही एक प्रोसेसर आणि 1 GB मेमरीसह सुरुवात करू शकता आणि हळूहळू शेकडो प्रोसेसर आणि 1 TB मेमरीपर्यंत वाढू शकता. VictoriaMetrics ही सर्व संसाधने वापरू शकते. 100-कोर सिस्टमच्या तुलनेत त्याची कार्यक्षमता सुमारे 1 पट वाढेल.

थानोसचा इतिहास नोव्हेंबर 2017 मध्ये सुरू झाला, जेव्हा प्रथम सार्वजनिक कमिट दिसून आले. याआधी, थानोस अंतर्गत विकसित केले गेले होते improbable.io.

जून 2019 मध्ये 0.5.0 एक ऐतिहासिक रिलीझ होते, ज्यामध्ये काढले गप्पाटप्पा प्रोटोकॉल त्याची कामगिरी चांगली न झाल्याने त्याला थानोसमधून काढून टाकण्यात आले. बर्‍याचदा थॅनोस क्लस्टर योग्यरित्या कार्य करत नाही, गॉसिप प्रोटोकॉलमुळे नोड्स चुकीच्या पद्धतीने कनेक्ट केले जातात. त्यामुळे आम्ही त्याला तेथून हटवण्याचा निर्णय घेतला. माझ्या मते हा योग्य निर्णय आहे.

त्याच जून 2019 मध्ये त्यांनी अर्ज क्रमांक पाठवला 256 в क्लाउड नेटिव्ह कम्प्यूटिंग फाउंडेशन.

आणि दोन महिन्यांनंतर थानोसला स्वीकारण्यात आले क्लाउड नेटिव्ह कम्प्यूटिंग फाउंडेशन, ज्यामध्ये Prometheus, Kubernetes आणि इतर लोकप्रिय प्रकल्पांचा समावेश आहे.

जानेवारी 2018 मध्ये, व्हिक्टोरियामेट्रिक्सचा विकास सुरू झाला.

सप्टेंबर 2018 मध्ये, मी पहिल्यांदा सार्वजनिकपणे VictoriaMetrics चा उल्लेख केला.

डिसेंबर 2018 मध्ये, सिंगल-नोड आवृत्ती प्रकाशित झाली.

मे मध्ये 2019 प्रकाशित झाले होते सिंगल-नोड आणि क्लस्टर आवृत्त्यांचे स्त्रोत.

जून 2019 मध्ये, थॅनोसप्रमाणेच, आम्ही CNCF फाउंडेशनला नंबर अंतर्गत अर्ज सादर केला 255. थॅनोसने अर्ज करण्याच्या एक दिवस आधी आम्ही अर्ज केला.

परंतु, दुर्दैवाने, आम्हाला अद्याप तेथे स्वीकारले गेले नाही. समुदायाची मदत आवश्यक आहे.

थॅनोस आणि व्हिक्टोरियामेट्रिक्सचे आर्किटेक्चर दर्शविणाऱ्या सर्वात महत्त्वाच्या स्लाइड्स पाहू.

चला थानोसपासून सुरुवात करूया. पिवळे घटक प्रोमिथियस घटक आहेत. बाकी सर्व काही थानोस घटक आहेत. चला सर्वात महत्वाच्या घटकासह प्रारंभ करूया. थानोस साइडकार हा एक घटक आहे जो प्रत्येक प्रोमिथियसच्या पुढे स्थापित केला जातो. हे स्थानिक स्टोरेजमधून प्रोमिथियस डेटा S3 किंवा अन्य ऑब्जेक्ट स्टोरेजमध्ये लोड करते.

थॅनोस स्टोअर गेटवे नावाचा एक घटक देखील आहे, जो थॅनोस क्वेरीकडून येणाऱ्या विनंत्यांवर ऑब्जेक्ट स्टोरेजमधून हा डेटा वाचू शकतो. Thanos Query PromQL आणि Prometheus API लागू करते. म्हणजेच, बाहेरून ते प्रोमिथियससारखे दिसते. PromQL क्वेरी प्राप्त करते, त्यांना थॅनोस स्टोअर गेटवेवर पाठवते, थॅनोस स्टोअर गेटवे ऑब्जेक्ट स्टोरेजमधून आवश्यक डेटा पुनर्प्राप्त करते, ते परत पाठवते.

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

तुम्ही हे कसे ठरवले? थॅनोस क्वेरी, थॅनोस स्टोअर गेटवेच्या विनंत्यांव्यतिरिक्त, प्रत्येक थानोस साइडकारला समांतर विनंत्या पाठवते, जे प्रोमिथियसच्या शेजारी स्थित आहे.

आणि थॅनोस साइडकार, या बदल्यात, प्रॉक्सीने प्रोमिथियसला विनंती केली आणि शेवटच्या दोन तासांचा डेटा पुनर्प्राप्त केला.

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

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

थानोसची ही सोपी योजना आहे.

आता त्याची तुलना VictoriaMetrics योजनेशी करू.

VictoriaMetrics च्या 2 आवृत्त्या आहेत: सिंगल-नोड आणि क्लस्टर आवृत्ती. सिंगल-नोड एका संगणकावर चालतो. सिंगल-नोडमध्ये हे घटक नसतात, फक्त एक बायनरी. स्लाइडवरील ही बायनरी या चौकोनसारखी दिसते. स्क्वेअरच्या आत असलेली प्रत्येक गोष्ट सिंगल-नोड आवृत्तीसाठी बायनरी फाइलची सामग्री आहे. तुम्हाला त्याच्याबद्दल माहिती असण्याची गरज नाही. तुम्ही फक्त बायनरी चालवा आणि सर्वकाही आमच्यासाठी कार्य करते.

क्लस्टर आवृत्ती अधिक क्लिष्ट आहे. त्याच्या आत तीन भिन्न घटक आहेत: vmselect, vminsert आणि vmstorage. त्यांच्या नावावरून हे स्पष्ट झाले पाहिजे की त्यांच्यापैकी प्रत्येकजण काय करतो. Insert घटक वेगवेगळ्या फॉरमॅटमध्ये डेटा स्वीकारतो: Prometheus remote write API, Influx line प्रोटोकॉल, Graphite प्रोटोकॉल आणि OpenTSDB प्रोटोकॉलमधून. घाला घटक त्यांना स्वीकारतो, त्यांचे विश्लेषण करतो आणि विद्यमान स्टोरेज घटकांमध्ये वितरित करतो, जिथे डेटा आधीच संग्रहित आहे. सिलेक्ट घटक, यामधून, PromQL क्वेरी स्वीकारतो. तो राबवतो PromQL, तसेच Prometheus querying API, आणि ते Grafana किंवा इतर Prometheus API क्लायंटमधील Prometheus साठी बदली म्हणून वापरले जाऊ शकते. सिलेक्ट promql विनंती स्वीकारते, त्याचे विश्लेषण करते, स्टोरेज नोड्समधून ही विनंती कार्यान्वित करण्यासाठी आवश्यक डेटा वाचते, या डेटावर प्रक्रिया करते आणि प्रतिसाद परत करते.

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

चला थानोसपासून सुरुवात करूया. तुम्ही Thanos सह काम सुरू करण्यापूर्वी, तुम्हाला S3 किंवा GCS सारख्या ऑब्जेक्ट स्टोरेजमध्ये एक बकेट तयार करणे आवश्यक आहे, जेणेकरून Thanos Sidecar त्यावर डेटा लिहू शकेल.

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

जेव्हा तुम्ही तुमच्या Prometheus वर Thanos Sidecar इंस्टॉल करता, तेव्हा तुम्ही हे डेटा कॉम्पॅक्शन अक्षम केले पाहिजे कारण Thanos Sidecar डेटा कॉम्पॅक्शन सक्षम करून योग्यरित्या कार्य करत नाही. याचा अर्थ असा की तुमचा Prometheus दोन-तासांच्या ब्लॉक्समध्ये डेटा वाचवण्यास सुरुवात करतो आणि त्या ब्लॉक्सला मोठ्या ब्लॉक्समध्ये विलीन करणे थांबवतो. त्यानुसार, जर तुम्ही शेवटच्या दोन तासांच्या कालावधीपेक्षा जास्त क्वेरी केल्या, तर डेटा कॉम्पॅक्शन सक्षम केले असल्यास ते कार्य करू शकतील तितक्या कार्यक्षमतेने कार्य करणार नाहीत.

त्यामुळे, थॅनोस मोठ्या संख्येने लहान ब्लॉक्सचे ओव्हरहेड कमी करण्यासाठी स्थानिक स्टोरेजमध्ये डेटा ठेवण्याची वेळ 6-8 तासांपर्यंत कमी करण्याची शिफारस करते.

एकदा तुम्ही Thanos Sidecar इंस्टॉल केल्यानंतर, तुम्ही प्रत्येक ऑब्जेक्ट स्टोरेज बकेटसाठी दोन घटक स्थापित केले पाहिजेत. हे थॅनोस कॉम्पॅक्टर आणि थानोस स्टोअर गेटवे आहेत.

त्यानंतर, तुम्हाला थॅनोस क्वेरी इन्स्टॉल करणे आणि कॉन्फिगर करणे आवश्यक आहे जेणेकरून ते तुमच्याकडे असलेल्या सर्व थॅनोस स्टोअर गेटवेशी कनेक्ट होऊ शकेल आणि सर्व थानोस साइडकारशी देखील कनेक्ट होऊ शकेल.

येथे थोडीशी समस्या असू शकते.

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

आपल्याकडे अशी अनेक डेटा केंद्रे असल्यास, त्यानुसार, संपूर्ण सिस्टमची विश्वासार्हता कमी होते. Thanos Query ने वेगवेगळ्या डेटा सेंटरमध्ये असलेल्या सर्व Thanos Sidecars चे कनेक्शन सतत राखले पाहिजेत. प्रत्येक येणार्‍या विनंतीसाठी, ते सर्व Thanos Sidecars ला विनंती पाठवेल. कनेक्शनमध्ये व्यत्यय आल्यास, तुम्हाला एकतर डेटाचा अपूर्ण संच मिळेल किंवा तुम्हाला "क्लस्टर इज डाउन" प्रतिसाद मिळेल.

VictoriaMetrics मध्ये सर्वकाही थोडे सोपे आहे. सिंगल-नोड आवृत्तीसाठी, तुम्हाला फक्त एक बायनरी चालवावी लागेल आणि सर्वकाही कार्य करेल.

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

तुम्ही एक बायनरी किंवा क्लस्टर केलेली आवृत्ती लाँच केल्यानंतर, तुम्हाला फक्त प्रोमिथियस कॉन्फिगरेशनमध्ये जोडणे आवश्यक आहे. रिमोट राइट url साठी सेटिंगजेणेकरून ते स्थानिक स्टोरेज आणि रिमोट स्टोरेजच्या समांतर डेटा लिहिण्यास सुरुवात करते. जसे आपण पाहू शकता, हे कॉन्फिगरेशन थानोस कॉन्फिगरेशनच्या तुलनेत अधिक विश्वासार्हपणे कार्य करते. आम्हाला व्हिक्टोरियामेट्रिक्सपासून सर्व प्रोमिथियसशी कनेक्शन राखण्याची गरज नाही, कारण प्रोमिथियस स्वतः व्हिक्टोरियामेट्रिक्सशी कनेक्ट होतात आणि डेटा प्रसारित करतात.

थॅनोस आणि व्हिक्टोरियामेट्रिक्सच्या समर्थनाचा विचार करूया.

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

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

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

थॅनोसमधील क्वेरी घटक या क्षणी काही साइडकार किंवा स्टोअर गेटवे उपलब्ध नसल्यास आंशिक परिणाम देते. तुम्हाला डेटाचा काही भाग प्राप्त होईल आणि तुम्हाला हे देखील कळणार नाही की तुम्हाला सर्व डेटा प्राप्त झाला नाही. हे डीफॉल्टनुसार कसे कार्य करते. अशाच परिस्थितीत, VictoriaMetrics चिन्हांकित डेटा आंशिक म्हणून परत करते.

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

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

थॅनोसच्या विपरीत, कुबर्नेट्स आपोआप क्लस्टर व्यवस्थापित करते. व्हिक्टोरियामेट्रिक्स क्लस्टर घटकांच्या विपरीत, सर्व थानोस घटक एका कुबर्नेट्स क्लस्टरमध्ये ठेवणे कठीण आहे.

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

VictoriaMetrics क्लस्टरचा विस्तार करणे खूप सोपे करते. फक्त आवश्यक घटक जोडा आणि कार्य करणे सुरू ठेवा.

थॅनोस आणि व्हिक्टोरियामेट्रिक्समधील त्रुटींबद्दल.

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

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

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

हे घटक असमानपणे लोड केले जाऊ शकतात. उदाहरणार्थ, तुमच्याकडे प्रोमिथियस आहे, जो प्रति सेकंद लाखो मेट्रिक्स गोळा करतो. आणि प्रोमिथियस आहे, जो प्रति सेकंद हजारो मेट्रिक्स गोळा करतो. प्रोमिथियस, जो प्रति सेकंद लाखो मेट्रिक्स गोळा करतो, तो ज्या सर्व्हरवर चालतो त्यावर खूप जास्त भार टाकतो. त्यानुसार साईडकार तेथे संथ गतीने काम करते. आणि सर्वसाधारणपणे सर्वकाही तेथे हळूहळू कार्य करते. आणि क्वेरी घटक तेथून डेटा अतिशय हळू खेचतो. त्यानुसार, तुमच्या संपूर्ण क्लस्टरची कार्यक्षमता या स्लो साइडकारद्वारे मर्यादित असेल.

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

VictoriaMetrics मध्ये देखील तोटे आहेत. पहिली अडचण हा पर्याय आहे जो VictoriaMetrics कॅशेसाठी वापरल्या जाणार्‍या RAM चे प्रमाण मर्यादित करतो. डीफॉल्टनुसार, ते व्हिक्टोरियामेट्रिक्स चालू असलेल्या मशीनवरील RAM च्या 60% किंवा कुबर्नेट्समधील व्हिक्टोरियामेट्रिक्स पॉडच्या RAM च्या 60% इतके असते.

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

दुसरा पर्याय. हा धारणा कालावधी आहे - एक कालावधी जो डीफॉल्टनुसार 1 महिन्यावर सेट केला जातो. VictoriaMetrics डेटा संचयित करते तो कालावधी आहे. या कालावधीनंतर, VictoriaMetrics डेटा हटवते.

बरेच लोक या पॅरामीटरशिवाय VictoriaMetrics चालवतात आणि एका महिन्यासाठी डेटा रेकॉर्ड करतात. आणि मग ते विचारतात: मागील महिन्याचा डेटा का गायब झाला? कारण डीफॉल्ट धारणा कालावधी 1 महिना आहे. म्हणून, तुम्हाला योग्य धारणा कालावधी माहित असणे आणि सेट करणे आवश्यक आहे.

चला अनन्य वैशिष्ट्यांवर एक नजर टाकूया.

थानोसमध्ये डाउनसॅम्पलिंग नावाचे वैशिष्ट्य आहे: 5-मिनिट आणि तासाचे अंतर, जे अनेकदा योग्यरित्या कार्य करत नाही. तुम्ही गुगल केले आणि गिथबवर त्यांची समस्या पाहिल्यास, या डाऊनसॅम्पलिंगशी संबंधित अनेक समस्या आहेत, की ते कधीकधी योग्यरित्या कार्य करत नाही किंवा वापरकर्त्यांच्या अपेक्षेप्रमाणे कार्य करत नाही.

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

थानोसमध्ये एक अलर्ट घटक आहे जो थानोस स्कीमॅटिकमध्ये होता. पण त्याला उत्पादनात वापरण्यासाठी शिफारस केलेली नाही.

थानोसचा फायदा आहे की थानोस आणि प्रोमिथियस समान कोड सामायिक करतात. थॅनोस आणि प्रोमिथियस एकाच विकसकाने विकसित केले आहेत. थॅनोस किंवा प्रोमिथियसच्या सुधारणेसह, दुसरी बाजू जिंकते.

VictoriaMetrics चे मुख्य वैशिष्ट्य MetricsQL आहे. हे PromQL साठी VictoriaMetrics विस्तार आहेत, ज्याबद्दल मी मागील मोठ्या मॉनिटरिंग मेटअपवर बोललो होतो.

VictoriaMetrics अनेक भिन्न प्रोटोकॉल वापरून डेटा लोडिंगला समर्थन देते. VictoriaMetrics केवळ Prometheus कडील डेटा स्वीकारू शकत नाही, तर Influx, OpenTSDB आणि Graphite प्रोटोकॉल द्वारे देखील.

Thanos आणि Prometheus च्या तुलनेत VictoriaMetrics डेटा खूपच कमी जागा घेतो.

आपण वास्तविक डेटा रेकॉर्ड केल्यास, वापरकर्ते प्रोमेथियस आणि थॅनोसच्या तुलनेत डिस्कवरील डेटाच्या आकारात 2-5 पट घट बद्दल बोलतात.

VictoriaMetrics चा आणखी एक फायदा म्हणजे तो वेगासाठी अनुकूल आहे.

पायाभूत सुविधांची किंमत पाहू.

थॅनॉसचा एक फायदा असा आहे की ते ऑब्जेक्ट स्टोरेजमध्ये डेटा संग्रहित करते, जे तुलनेने स्वस्त आहे.

ऑब्जेक्ट स्टोरेजमध्ये डेटा संचयित करताना, आपण डेटा लेखन आणि वाचन ऑपरेशन्ससाठी ($10 प्रति दशलक्ष ऑपरेशन्स) देय देणे आवश्यक आहे. जेव्हा तुम्ही ऑब्जेक्ट स्टोरेजमध्ये डेटा लिहिता, तेव्हा तुम्ही इंटरनेटवर डेटा अपलोड करण्यासाठी तुमची होस्टिंग किंमत भरता; तुमचा क्लस्टर AWS मध्ये नसल्यास, ते तेथे विनामूल्य आहे. तुम्ही डेटा वाचता तेव्हा, तुम्ही प्रति 10TB $230 आणि $1 दरम्यान पैसे द्या. तुम्ही थॅनोस क्लस्टरमधील ऐतिहासिक डेटाची वारंवार चौकशी करत असल्यास हे महत्त्वपूर्ण असू शकते.

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

VictoriaMetrics चे खालील खर्च आहेत. तुम्ही GCE HDD ड्राइव्हवर डेटा साठवल्यास, तो 40TB साठी $1 वर येतो. व्हिक्टोरियामेट्रिक्ससाठी, सामान्य एचडीडी ड्राइव्ह पुरेसे आहेत; कोणत्याही एसएसडीची आवश्यकता नाही, ज्याची किंमत पाच पट जास्त आहे. VictoriaMetrics HDD साठी ऑप्टिमाइझ केले आहे.

VictoriaMetrics ला घटकांसाठी सर्व्हरची आवश्यकता असते: एकतर एकल-नोड किंवा क्लस्टर केलेले घटक, ज्यांना, थानोस घटकांप्रमाणे, खूपच कमी CPU आणि RAM आवश्यक आहे - आणि त्यानुसार स्वस्त असेल.

अंमलबजावणीची उदाहरणे.

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

त्यामुळे या समस्या सोडवण्याचा खर्च वाढतो.

दुसरी अंमलबजावणी, जी कदाचित अधिक यशस्वी होऊ शकते, ती म्हणजे इम्प्रोबेबल कंपनी, ज्याने थानोस विकसित करण्यास सुरुवात केली. त्यांनी थानोस स्त्रोत कोड प्रकाशित केला. इम्प्रोबबल ही एक कंपनी आहे जी गेम इंजिन विकसित करते.

VictoriaMetrics मध्ये सार्वजनिक अंमलबजावणी उदाहरणे आहेत:

• wix.com वेबसाइट बिल्डर
• Adidas VictoriaMetrics ची अंमलबजावणी करत आहे आणि शेवटच्या PromCon 2019 मध्ये एक सादरीकरण देखील केले आहे
• ट्रॅफिकस्टार्स - जाहिरात नेटवर्क
• Seznam.cz हे एक लोकप्रिय झेक शोध इंजिन आहे.

आणि नंतर अशा नो-नाव कंपन्या होत्या ज्यांना मी आता नाव देऊ शकत नाही. त्यांनी संमती दिली नाही.

• एक प्रमुख गेम डेव्हलपर. Improbable पेक्षा मोठा.
• प्रमुख ग्राफिक्स सॉफ्टवेअर डेव्हलपर.
• मोठी रशियन बँक.
• युरोपियन विंड टर्बाइन निर्माता ज्याने व्हिक्टोरियामेट्रिक्सची यशस्वी चाचणी केली आहे. हा निर्माता पवन टर्बाइनमधून संकलित केलेल्या डेटाचे निरीक्षण करण्यासाठी 50 नमुने प्रति सेकंद प्रति सेन्सर या दराने VictoriaMetrics कार्यान्वित करत आहे. प्रत्येक पवन टर्बाइनमध्ये शंभर सेन्सर असतात. त्यांच्याकडे शेकडो पवन टर्बाइन आहेत.
• रशियन एअरलाइन्स ज्यांना व्हिक्टोरियामेट्रिक्सची अंमलबजावणी करायची आहे, परंतु तरीही करू शकत नाही. आम्ही त्यांच्यासोबत कराराच्या टप्प्यावर आहोत.

निष्कर्ष.

VictoriaMetrics आणि Thanos समान समस्या सोडवतात, परंतु भिन्न मार्गांनी:

• जागतिक क्वेरी दृश्य
• क्षैतिज स्केलिंग
• अनियंत्रित धारणा

Спасибо.

आम्ही आमच्या येथे तुमची वाट पाहत आहोत टेलिग्राम चॅनेल.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

प्रोमिथियससाठी दीर्घकालीन स्टोरेज म्हणून तुम्ही काय वापरता?

• 35,3%थानोस6

• 0,0%कॉर्टेक्स0

• 0,0%M3DB0

• 41,2%व्हिक्टोरियामेट्रिक्स7

• 23,5%इतर4

17 वापरकर्त्यांनी मतदान केले. 16 वापरकर्ते दूर राहिले.

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