व्हिक्टोरियामेट्रिक्स आणि खाजगी क्लाउड मॉनिटरिंग. पावेल कोलोबाएव

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

माझे नाव कोलोबाएव पावेल आहे. DevOps, SRE, LeroyMerlin, सर्वकाही कोडसारखे आहे - हे सर्व आपल्याबद्दल आहे: माझ्याबद्दल आणि इतर LeroyMerlin कर्मचाऱ्यांबद्दल.

https://bit.ly/3jf1fIK

OpenStack वर आधारित क्लाउड आहे. तांत्रिक रडारचा एक छोटासा दुवा आहे.

हे Kubernetes हार्डवेअर, तसेच OpenStack आणि लॉगिंगसाठी सर्व संबंधित सेवांवर तयार केले आहे.

ही योजना आमच्याकडे विकासात होती. जेव्हा आम्ही हे सर्व विकसित करत होतो, तेव्हा आमच्याकडे एक प्रोमिथियस ऑपरेटर होता जो K8s क्लस्टरमध्येच डेटा संग्रहित करतो. जे घासणे आवश्यक आहे ते तो आपोआप शोधतो आणि त्याच्या पायाखाली ठेवतो, ढोबळमानाने.

आम्हाला सर्व डेटा कुबर्नेट्स क्लस्टरच्या बाहेर हलवावा लागेल, कारण काही घडल्यास, काय आणि कुठे हे समजून घेणे आवश्यक आहे.

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

परंतु येथे काही लहान समस्या आहेत. आमच्या बाबतीत, आमच्याकडे 250 मेट्रिक्स असताना समस्या सुरू झाल्या आणि जेव्हा 000 मेट्रिक्स होत्या, तेव्हा आम्हाला समजले की आम्ही असे काम करू शकत नाही. आम्ही scrape_timeout 400 सेकंदांपर्यंत वाढवले.

आम्हाला हे का करावे लागले? प्रोमिथियस कुंपणाच्या सुरुवातीपासूनच कालबाह्य मोजणे सुरू करतो. डेटा अजूनही प्रवाहित आहे हे काही फरक पडत नाही. जर या निर्दिष्ट कालावधीत डेटा विलीन केला गेला नाही आणि सत्र HTTP द्वारे बंद केले गेले नाही, तर सत्र अयशस्वी झाल्याचे मानले जाते आणि डेटा प्रोमिथियसमध्येच येत नाही.

जेव्हा काही डेटा गहाळ असतो तेव्हा आम्हाला जे आलेख मिळतात ते प्रत्येकजण परिचित आहे. वेळापत्रक फाटले आहे आणि त्यामुळे आम्ही आनंदी नाही.

पुढील पर्याय समान फेडरेशन यंत्रणेद्वारे दोन भिन्न प्रोमिथियसवर आधारित शार्डिंग आहे.

उदाहरणार्थ, फक्त त्यांना घ्या आणि नावाने तुकडे करा. हे देखील वापरले जाऊ शकते, परंतु आम्ही पुढे जाण्याचा निर्णय घेतला.

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

पहिला पर्याय असा आहे की आम्हाला फेडरेशनची यंत्रणा सोडून द्यायची आहे कारण ती अतिशय संथ आहे.

प्रोमिथियस डेव्हलपर स्पष्टपणे म्हणत आहेत, "मित्रांनो, वेगळा TimescaleDB वापरा कारण आम्ही मेट्रिक्सच्या दीर्घकालीन स्टोरेजला सपोर्ट करणार नाही." हे त्यांचे कार्य नाही.

आम्ही कागदाच्या तुकड्यावर लिहून ठेवतो जे आम्हाला अजूनही बाहेरून उतरवायचे आहे, जेणेकरून सर्व काही एकाच ठिकाणी ठेवू नये.

दुसरा दोष मेमरी वापर आहे. होय, मला समजले आहे की बरेच लोक म्हणतील की 2020 मध्ये दोन गीगाबाइट मेमरी एक पैसा खर्च करते, परंतु तरीही.

आता आमच्याकडे देव आणि उत्पादन वातावरण आहे. dev मध्ये ते 9 मेट्रिक्ससाठी सुमारे 350 गीगाबाइट्स आहे. उत्पादनामध्ये ते 000 गीगाबाइट्स आणि 14 मेट्रिक्सपेक्षा थोडे जास्त आहे. त्याच वेळी, आमची धारणा वेळ फक्त 780 मिनिटे आहे. हे वाईट आहे. आणि आता मी याचे कारण सांगेन.

आम्ही एक गणना करतो, म्हणजेच दीड दशलक्ष मेट्रिक्ससह, आणि आम्ही आधीच त्यांच्या जवळ आहोत, डिझाइन टप्प्यावर आम्हाला 35-37 गीगाबाइट मेमरी मिळते. परंतु आधीच 4 दशलक्ष मेट्रिक्ससाठी सुमारे 90 गीगाबाइट मेमरी आवश्यक आहे. म्हणजेच, प्रोमिथियस विकसकांनी प्रदान केलेल्या सूत्राचा वापर करून त्याची गणना केली गेली. आम्ही परस्परसंबंध पाहिला आणि लक्षात आले की आम्ही केवळ देखरेखीसाठी सर्व्हरसाठी काही दशलक्ष देऊ इच्छित नाही.

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

डिस्क स्पेससह, येथे सर्वकाही इतके खराब नाही, परंतु मला ते सुधारायचे आहे. आम्हाला 15 दिवसात एकूण 120 गीगाबाइट्स प्राप्त झाले, त्यापैकी 100 संकुचित डेटा आहेत, 20 असंपीडित डेटा आहेत, परंतु आम्हाला नेहमी कमी हवे आहेत.

त्यानुसार, आम्ही आणखी एक मुद्दा लिहितो - हा संसाधनांचा मोठा वापर आहे, जो आम्हाला अजूनही जतन करायचा आहे, कारण आम्हाला आमच्या मॉनिटरिंग क्लस्टरने आमच्या क्लस्टरपेक्षा अधिक संसाधने वापरायची नाहीत, जे OpenStack व्यवस्थापित करते.

प्रोमिथियसची आणखी एक कमतरता आहे, जी आम्ही स्वतःसाठी ओळखली आहे, ही किमान एक प्रकारची स्मृती मर्यादा आहे. प्रोमिथियससह, येथे सर्व काही खूपच वाईट आहे, कारण त्यात असे ट्विस्ट अजिबात नाहीत. डॉकरमध्ये मर्यादा वापरणे देखील पर्याय नाही. जर तुमचा आरएएफ अचानक पडला आणि 20-30 गीगाबाइट्स असतील तर ते वाढण्यास खूप वेळ लागेल.

प्रोमिथियस आपल्यासाठी योग्य नसण्याचे हे आणखी एक कारण आहे, म्हणजे आपण मेमरी वापर मर्यादित करू शकत नाही.

अशी योजना आणणे शक्य होईल. HA क्लस्टर आयोजित करण्यासाठी आम्हाला या योजनेची आवश्यकता आहे. हे मेट्रिक्स संचयित करणारा सर्व्हर क्रॅश झाला तरीही आमची मेट्रिक्स नेहमी आणि सर्वत्र उपलब्ध असावी अशी आमची इच्छा आहे. आणि अशा प्रकारे आपल्याला अशी योजना तयार करावी लागेल.

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

ज्या फॉर्ममध्ये आम्ही ते स्वतःसाठी लिहिले त्या क्रमाने तोटे:

• मेट्रिक्स बाहेरून अपलोड करणे आवश्यक आहे.
• उच्च संसाधनांचा वापर.
• मेमरी वापर मर्यादित करण्याचा कोणताही मार्ग नाही.
• HA ची जटिल आणि संसाधन-केंद्रित अंमलबजावणी.

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

आम्ही स्वतःसाठी आवश्यक असलेल्या अतिरिक्त आवश्यकता ओळखल्या आहेत. हे:

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

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

का? कारण:

• promql करू शकतो.
• एक मॉड्यूलर आर्किटेक्चर आहे.
• Grafana मध्ये बदल आवश्यक नाही.
• आणि सर्वात महत्त्वाचे म्हणजे, आम्ही आमच्या कंपनीमध्ये मेट्रिक्स स्टोरेज सेवा म्हणून प्रदान करू, म्हणून आम्ही विविध प्रकारच्या निर्बंधांकडे आगाऊ विचार करत आहोत जेणेकरून वापरकर्ते क्लस्टरची सर्व संसाधने काही मर्यादित मार्गाने वापरू शकतील, कारण तेथे एक संधी आहे. ते बहुभाडेपणा करेल.

चला पहिली तुलना करूया. आम्ही समान प्रोमिथियस क्लस्टरच्या आत घेतो, बाह्य प्रोमिथियस त्याच्याकडे जातो. रिमोटराईट व्हिक्टोरियामेट्रिक्सद्वारे जोडा.

मी ताबडतोब आरक्षण करेन की येथे आम्ही व्हिक्टोरियामेट्रिक्सकडून CPU वापरामध्ये थोडीशी वाढ केली आहे. VictoriaMetrics विकी तुम्हाला कोणते पॅरामीटर्स सर्वोत्तम आहेत ते सांगतो. आम्ही त्यांना तपासले. त्यांनी CPU चा वापर खूपच कमी केला आहे.

आमच्या बाबतीत, कुबर्नेट्स क्लस्टरमध्ये असलेल्या प्रोमिथियसच्या मेमरी वापरामध्ये लक्षणीय वाढ झाली नाही.

आम्ही एकाच डेटाच्या दोन डेटा स्रोतांची तुलना करतो. प्रोमिथियसमध्ये आपण समान गहाळ डेटा पाहतो. VictoriaMetrics वर सर्व काही ठीक आहे.

डिस्क स्पेस चाचणी परिणाम. Prometheus येथे आम्हाला एकूण 120 गीगाबाइट्स मिळाले. VictoriaMetrics वर आम्हाला आधीच दररोज 4 गीगाबाइट्स मिळतात. प्रोमिथियसमध्ये पाहण्याची आपल्याला सवय आहे त्यापेक्षा थोडी वेगळी यंत्रणा आहे. म्हणजेच, एका दिवसात, अर्ध्या तासात डेटा आधीच चांगला संकुचित केला जातो. ते आधीच एका दिवसात, अर्ध्या तासात चांगले कापले गेले आहेत, तरीही डेटा नंतर गमावला जाईल. परिणामी, आम्ही डिस्क स्पेसवर बचत केली.

आम्ही मेमरी संसाधनाच्या वापरावर देखील बचत करतो. चाचणीच्या वेळी, आम्ही प्रोमिथियसला आभासी मशीनवर तैनात केले होते - 8 कोर, 24 गीगाबाइट्स. प्रोमिथियस जवळजवळ सर्व काही खातो. तो ओओएम किलरवर पडला. त्याच वेळी, त्यात फक्त 900 सक्रिय मेट्रिक्स ओतले गेले. हे प्रति सेकंद सुमारे 000-25 मेट्रिक्स आहे.

आम्ही 8 गीगाबाइट RAM सह ड्युअल-कोर व्हर्च्युअल मशीनवर VictoriaMetrics चालवले. आम्ही 8GB मशिनवर काही गोष्टींसह व्हिक्टोरियामेट्रिक्सला चांगले कार्य करण्यास व्यवस्थापित केले. शेवटी, आम्ही ते 7 गीगाबाइट्सवर ठेवले. त्याच वेळी, सामग्रीच्या वितरणाची गती, म्हणजे मेट्रिक्स, प्रोमेथियसच्या तुलनेत अधिक होती.

प्रोमिथियसच्या तुलनेत सीपीयू खूपच चांगला झाला आहे. येथे प्रोमिथियस 2,5 कोर वापरतो आणि व्हिक्टोरियामेट्रिक्स फक्त 0,25 कोर वापरतो. सुरुवातीला - 0,5 कोर. जसजसे ते विलीन होते, ते एका गाभ्यापर्यंत पोहोचते, परंतु हे अत्यंत, अत्यंत दुर्मिळ आहे.

आमच्या बाबतीत, निवड स्पष्ट कारणांसाठी VictoriaMetrics वर पडली; आम्हाला पैसे वाचवायचे होते आणि आम्ही ते केले.

चला लगेचच दोन मुद्दे ओलांडू - मेट्रिक्स अपलोड करणे आणि संसाधनांचा उच्च वापर. आणि आपल्याला फक्त दोन मुद्दे ठरवायचे आहेत जे आपण अद्याप आपल्यासाठी सोडले आहेत.

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

एक अद्भुत पॅरामीटर आहे जो आपल्याला वेळेनुसार, डेटाच्या प्रमाणानुसार आणि अंमलबजावणीच्या वेळेनुसार मर्यादित करण्यास अनुमती देतो.

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

उणे आणखी एक बिंदू, म्हणजे बिंदू पार करा - तुम्ही मेमरी वापर मर्यादित करू शकत नाही.

पहिल्या पुनरावृत्तीमध्ये, आम्ही VictoriaMetrics सिंगल नोडची चाचणी केली. पुढे आपण व्हिक्टोरियामेट्रिक्स क्लस्टर आवृत्तीकडे जाऊ.

व्हिक्टोरियामेट्रिक्समध्ये वेगवेगळ्या सेवा कशावर चालतील आणि ते कोणत्या संसाधनांचा वापर करतील यावर अवलंबून विभक्त करण्यासाठी आमच्याकडे मोकळा हात आहे. हा एक अतिशय लवचिक आणि सोयीस्कर उपाय आहे. आम्ही हे स्वतःवर वापरले.

VictoriaMetrics क्लस्टर आवृत्तीचे मुख्य घटक vmstsorage आहेत. त्यांची संख्या N असू शकते. आमच्या बाबतीत आतापर्यंत त्यापैकी 2 आहेत.

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

Vminsert Prometheus कडून OpenTSDB, Graphite, InfluxDB आणि remoteWrite प्रोटोकॉलचे समर्थन करते.

vmselect देखील आहे. त्याचे मुख्य कार्य म्हणजे vmstorage वर जाणे, त्यांच्याकडून डेटा प्राप्त करणे, हा डेटा डुप्लिकेट करणे आणि क्लायंटला देणे.

vmagent नावाची एक अद्भुत गोष्ट आहे. आम्हाला ती खरोखर आवडते. हे तुम्हाला Prometheus प्रमाणेच कॉन्फिगर करण्याची आणि तरीही Prometheus प्रमाणेच सर्वकाही करण्यास अनुमती देते. म्हणजेच, ते वेगवेगळ्या संस्था आणि सेवांकडून मेट्रिक्स गोळा करते आणि त्यांना vminsert वर पाठवते. मग सर्व काही तुमच्यावर अवलंबून आहे.

दुसरी उत्तम सेवा vmalert आहे, जी तुम्हाला व्हिक्टोरियामेट्रिक्सचा बॅकएंड म्हणून वापर करण्यास, vminsert कडून प्रक्रिया केलेला डेटा प्राप्त करण्यास आणि vmselect वर पाठविण्यास अनुमती देते. ते स्वतः सूचनांवर तसेच नियमांवर प्रक्रिया करते. अलर्ट्सच्या बाबतीत, आम्हाला अलर्ट मॅनेजर द्वारे अलर्ट प्राप्त होतो.

एक wmauth घटक आहे. आम्ही क्लस्टर्सच्या मल्टीटेनन्सी आवृत्तीसाठी अधिकृतता प्रणाली म्हणून वापरू शकतो किंवा नाही (आम्ही अद्याप यावर निर्णय घेतलेला नाही). हे Prometheus साठी remoteWrite चे समर्थन करते आणि url वर आधारित अधिकृत करू शकते, किंवा त्याऐवजी त्याचा दुसरा भाग, जिथे तुम्ही लिहू शकता किंवा करू शकत नाही.

vmbackup, vmrestore देखील आहे. हे, थोडक्यात, सर्व डेटाचे पुनर्संचयित आणि बॅकअप आहे. S3, GCS, फाइल करू शकता.

आमच्या क्लस्टरची पहिली पुनरावृत्ती क्वारंटाईन दरम्यान केली गेली. त्या वेळी, कोणतीही प्रतिकृती नव्हती, म्हणून आमच्या पुनरावृत्तीमध्ये दोन भिन्न आणि स्वतंत्र क्लस्टर होते ज्यामध्ये आम्हाला रिमोटराईटद्वारे डेटा प्राप्त झाला.

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

येथे एक प्रतिकृती आधीच जोडली गेली आहे. आम्ही हे सर्व एका तुलनेने मोठ्या क्लस्टरमध्ये एकत्र केले. आमचा सर्व डेटा शार्ड आणि प्रतिकृती दोन्ही आहे.

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

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

आमच्याकडे अलर्ट आहे. आम्ही ते वापरतो. आम्ही प्रोमिथियसचे अलर्ट मॅनेजर वापरतो. आम्ही Opsgenie आणि Telegram चा वापर अलर्ट वितरण चॅनेल म्हणून करतो. टेलीग्राममध्ये ते dev वरून ओततात, कदाचित उत्पादनातून काहीतरी, परंतु मुख्यतः काहीतरी सांख्यिकीय, अभियंत्यांना आवश्यक आहे. आणि Opsgenie गंभीर आहे. हे कॉल्स आहेत, घटना व्यवस्थापन.

शाश्वत प्रश्न: "निरीक्षणावर कोण लक्ष ठेवते?" आमच्या बाबतीत, मॉनिटरिंग मॉनिटर स्वतःचे निरीक्षण करतो, कारण आम्ही प्रत्येक नोडवर vmagent वापरतो. आणि आमचे नोड्स एकाच प्रदात्याच्या वेगवेगळ्या डेटा सेंटरमध्ये वितरीत केले जात असल्याने, प्रत्येक डेटा सेंटरचे स्वतःचे चॅनेल आहे, ते स्वतंत्र आहेत आणि एक विभाजित मेंदू आला तरीही आम्हाला अलर्ट प्राप्त होईल. होय, त्यापैकी बरेच असतील, परंतु कोणत्याहीपेक्षा अधिक सूचना प्राप्त करणे चांगले आहे.

आम्ही आमची यादी HA अंमलबजावणीसह समाप्त करतो.

आणि पुढे मी VictoriaMetrics समुदायाशी संवाद साधण्याचा अनुभव लक्षात घेऊ इच्छितो. तो खूप सकारात्मक निघाला. मुले प्रतिसाद देणारे आहेत. ते ऑफर केलेल्या प्रत्येक प्रकरणात सखोल प्रयत्न करतात.

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

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

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

क्लस्टरच्या अंमलबजावणीत सुधारणा करण्याचे प्रस्ताव आहेत. मी त्यांना वर वर्णन केले आहे.

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

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

आम्ही घरी VictoriaMetrics वापरू कारण आम्हाला ते खरोखर आवडले. हेच होते आणि काय बनले आहे.

https://t.me/VictoriaMetrics_ru1

VictoriaMetrics चॅट, माझे संपर्क, LeroyMerlin तांत्रिक रडारसाठी काही QR कोड.

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