विक्टोरियामेट्रिक्स और निजी क्लाउड मॉनिटरिंग। पावेल कोलोबेव

विक्टोरियामेट्रिक्स समय श्रृंखला के रूप में डेटा को संग्रहीत और संसाधित करने के लिए एक तेज़ और स्केलेबल डीबीएमएस है (एक रिकॉर्ड में समय और इस समय के अनुरूप मूल्यों का एक सेट होता है, उदाहरण के लिए, सेंसर की स्थिति के आवधिक मतदान के माध्यम से प्राप्त किया जाता है या मेट्रिक्स का संग्रह)।

मेरा नाम कोलोबेव पावेल है। DevOps, SRE, LeroyMerlin, सब कुछ कोड की तरह है - यह सब हमारे बारे में है: मेरे बारे में और अन्य LeroyMerlin कर्मचारियों के बारे में।

https://bit.ly/3jf1fIK

ओपनस्टैक पर आधारित एक क्लाउड है। तकनीकी रडार के लिए एक छोटा सा लिंक है।

यह कुबेरनेट्स हार्डवेयर के साथ-साथ ओपनस्टैक और लॉगिंग के लिए सभी संबंधित सेवाओं पर बनाया गया है।

यह वह योजना है जिसे हमने विकसित किया था। जब हम यह सब विकसित कर रहे थे, हमारे पास एक प्रोमेथियस ऑपरेटर था जो K8s क्लस्टर के अंदर ही डेटा संग्रहीत करता था। वह स्वचालित रूप से पता लगा लेता है कि क्या साफ़ करना है और मोटे तौर पर कहें तो उसे अपने पैरों के नीचे रख लेता है।

हमें सभी डेटा को कुबेरनेट्स क्लस्टर के बाहर ले जाने की आवश्यकता होगी, क्योंकि अगर कुछ होता है, तो हमें यह समझने की आवश्यकता है कि क्या और कहाँ।

पहला समाधान यह है कि हम फेडरेशन का उपयोग तब करते हैं जब हमारे पास तृतीय-पक्ष प्रोमेथियस होता है, जब हम फेडरेशन तंत्र के माध्यम से कुबेरनेट्स क्लस्टर में जाते हैं।

लेकिन यहां कुछ छोटी-मोटी समस्याएं हैं. हमारे मामले में, समस्याएँ तब शुरू हुईं जब हमारे पास 250 मीट्रिक थीं, और जब 000 मीट्रिक थीं, तो हमें एहसास हुआ कि हम उस तरह काम नहीं कर सकते। हमने स्क्रैप_टाइमआउट को 400 सेकंड तक बढ़ा दिया है।

हमें ऐसा क्यों करना पड़ा? प्रोमेथियस बाड़ की शुरुआत से टाइमआउट की गिनती शुरू करता है। इससे कोई फर्क नहीं पड़ता कि डेटा अभी भी प्रवाहित हो रहा है। यदि इस निर्दिष्ट अवधि के दौरान डेटा मर्ज नहीं किया जाता है और सत्र http के माध्यम से बंद नहीं किया जाता है, तो सत्र विफल माना जाता है और डेटा प्रोमेथियस में ही नहीं आता है।

हर कोई उस ग्राफ़ से परिचित है जो हमें तब मिलता है जब कुछ डेटा गायब होता है। शेड्यूल फटा हुआ है और हम इससे खुश नहीं हैं।'

अगला विकल्प एक ही फेडरेशन तंत्र के माध्यम से दो अलग-अलग प्रोमेथियस पर आधारित शार्डिंग है।

उदाहरण के लिए, बस उन्हें लें और नाम लेकर टुकड़े-टुकड़े कर दें। इसका भी उपयोग किया जा सकता है, लेकिन हमने आगे बढ़ने का फैसला किया।

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

पहला विकल्प यह है कि हम फेडरेशन तंत्र को छोड़ना चाहते हैं क्योंकि यह बहुत धीमा है।

प्रोमेथियस डेवलपर्स स्पष्ट रूप से कह रहे हैं, "दोस्तों, एक अलग टाइमस्केलडीबी का उपयोग करें क्योंकि हम मेट्रिक्स के दीर्घकालिक भंडारण का समर्थन नहीं करेंगे।" ये उनका काम नहीं है.

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

दूसरा दोष है मेमोरी खपत. हां, मैं समझता हूं कि कई लोग कहेंगे कि 2020 में एक-दो गीगाबाइट मेमोरी की कीमत एक पैसा है, लेकिन फिर भी।

अब हमारे पास एक विकास और उत्पाद वातावरण है। डेव में यह 9 मेट्रिक्स के लिए लगभग 350 गीगाबाइट है। उत्पाद में यह 000 गीगाबाइट और 14 मेट्रिक्स से थोड़ा अधिक है। वहीं, हमारा रिटेंशन टाइम सिर्फ 780 मिनट है। यह तो बुरा हुआ। और अब मैं समझाऊंगा क्यों।

हम गणना करते हैं, यानी, डेढ़ मिलियन मीट्रिक के साथ, और हम पहले से ही उनके करीब हैं, डिजाइन चरण में हमें 35-37 गीगाबाइट मेमोरी मिलती है। लेकिन पहले से ही 4 मिलियन मेट्रिक्स के लिए लगभग 90 गीगाबाइट मेमोरी की आवश्यकता होती है। यानी, इसकी गणना प्रोमेथियस डेवलपर्स द्वारा उपलब्ध कराए गए फॉर्मूले का उपयोग करके की गई थी। हमने सहसंबंध को देखा और महसूस किया कि हम केवल निगरानी के लिए सर्वर के लिए कुछ मिलियन का भुगतान नहीं करना चाहते थे।

हम न केवल मशीनों की संख्या बढ़ाएंगे, बल्कि वर्चुअल मशीनों की निगरानी भी खुद कर रहे हैं। इसलिए, जितनी अधिक आभासी मशीनें होंगी, विभिन्न प्रकार के उतने ही अधिक मेट्रिक्स आदि होंगे। मेट्रिक्स के संदर्भ में हमारे क्लस्टर की विशेष वृद्धि होगी।

डिस्क स्थान के साथ, यहां सब कुछ इतना बुरा नहीं है, लेकिन मैं इसे सुधारना चाहूंगा। हमें 15 दिनों में कुल 120 गीगाबाइट प्राप्त हुए, जिनमें से 100 संपीड़ित डेटा हैं, 20 असंपीड़ित डेटा हैं, लेकिन हम हमेशा कम चाहते हैं।

तदनुसार, हम एक और बिंदु लिखते हैं - यह संसाधनों की एक बड़ी खपत है, जिसे हम अभी भी बचाना चाहते हैं, क्योंकि हम नहीं चाहते कि हमारा मॉनिटरिंग क्लस्टर हमारे क्लस्टर की तुलना में अधिक संसाधनों का उपभोग करे, जो ओपनस्टैक का प्रबंधन करता है।

प्रोमेथियस की एक और कमी है, जिसे हमने स्वयं पहचाना है, यह कम से कम किसी प्रकार की स्मृति सीमा है। प्रोमेथियस के साथ, यहां सब कुछ बहुत खराब है, क्योंकि इसमें ऐसे कोई मोड़ नहीं हैं। डॉकर में सीमा का उपयोग करना भी एक विकल्प नहीं है। यदि अचानक आपका RAF गिर गया और 20-30 गीगाबाइट बचे हैं, तो इसे उठने में बहुत लंबा समय लगेगा।

यह एक और कारण है कि प्रोमेथियस हमारे लिए उपयुक्त नहीं है, यानी हम मेमोरी खपत को सीमित नहीं कर सकते।

ऐसी योजना लाना संभव होगा. एचए क्लस्टर को व्यवस्थित करने के लिए हमें इस योजना की आवश्यकता है। हम चाहते हैं कि हमारे मेट्रिक्स हमेशा और हर जगह उपलब्ध रहें, भले ही इन मेट्रिक्स को संग्रहीत करने वाला सर्वर क्रैश हो जाए। और इसलिए हमें एक ऐसी योजना बनानी होगी।

यह योजना कहती है कि हमारे पास टुकड़ों का दोहराव होगा, और, तदनुसार, उपभोग किए गए संसाधनों की लागत का दोहराव होगा। इसे लगभग क्षैतिज रूप से बढ़ाया जा सकता है, लेकिन फिर भी संसाधन की खपत नारकीय होगी।

नुकसान उस क्रम में जिस रूप में हमने उन्हें अपने लिए लिखा था:

• मेट्रिक्स को बाह्य रूप से अपलोड करने की आवश्यकता है.
• उच्च संसाधन खपत।
• मेमोरी खपत को सीमित करने का कोई तरीका नहीं है।
• एचए का जटिल और संसाधन-गहन कार्यान्वयन।

अपने लिए, हमने निर्णय लिया कि हम भंडारण सुविधा के रूप में प्रोमेथियस से दूर जा रहे हैं।

हमने अपने लिए अतिरिक्त आवश्यकताओं की पहचान की है जिनकी हमें आवश्यकता है। यह:

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

विकल्प बहुत कम था. हमने वह सब कुछ एकत्र किया जिसका हमें अनुभव था। हमने एकीकरण अनुभाग में प्रोमेथियस पृष्ठ को देखा, बहुत सारे लेख पढ़े, और देखा कि वहां क्या था। और अपने लिए, हमने प्रोमेथियस के प्रतिस्थापन के रूप में विक्टोरियामेट्रिक्स को चुना।

क्यों? क्योंकि:

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

आइए पहली तुलना करें. हम उसी प्रोमेथियस को क्लस्टर के अंदर लेते हैं, बाहरी प्रोमेथियस उसके पास जाता है। रिमोटराइट विक्टोरियामेट्रिक्स के माध्यम से जोड़ें।

मैं तुरंत आरक्षण कर दूंगा कि यहां हमने विक्टोरियामेट्रिक्स से सीपीयू खपत में मामूली वृद्धि देखी है। विक्टोरियामेट्रिक्स विकी आपको बताता है कि कौन से पैरामीटर सर्वोत्तम हैं। हमने उनकी जांच की. उन्होंने CPU खपत को बहुत कम कर दिया है।

हमारे मामले में, कुबेरनेट्स क्लस्टर में स्थित प्रोमेथियस की मेमोरी खपत में उल्लेखनीय वृद्धि नहीं हुई।

हम एक ही डेटा के दो डेटा स्रोतों की तुलना करते हैं। प्रोमेथियस में हम वही गायब डेटा देखते हैं। विक्टोरियामेट्रिक्स में सब कुछ ठीक है।

डिस्क स्थान परीक्षण के परिणाम. प्रोमेथियस में हमें कुल मिलाकर 120 गीगाबाइट प्राप्त हुए। विक्टोरियामेट्रिक्स में हमें पहले से ही प्रति दिन 4 गीगाबाइट मिलते हैं। हम प्रोमेथियस में जो देखने के आदी हैं, उससे थोड़ा अलग तंत्र है। यानी एक दिन में आधे घंटे में ही डेटा काफी अच्छे से कंप्रेस हो जाता है। उन्हें पहले ही एक दिन में, आधे घंटे में अच्छी तरह से प्राप्त किया जा चुका है, इस तथ्य के बावजूद कि डेटा अभी भी बाद में खो जाएगा। परिणामस्वरूप, हमने डिस्क स्थान बचा लिया।

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

हमने विक्टोरियामेट्रिक्स को 8 गीगाबाइट रैम वाली डुअल-कोर वर्चुअल मशीन पर चलाया। हम 8 जीबी मशीन पर कुछ चीजों के साथ छेड़छाड़ करके विक्टोरियामेट्रिक्स को अच्छी तरह से काम करने में कामयाब रहे। अंत में, हमने इसे 7 गीगाबाइट तक रखा। साथ ही, सामग्री की डिलीवरी की गति, यानी मेट्रिक्स, प्रोमेथियस से भी अधिक थी।

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

हमारे मामले में, स्पष्ट कारणों से चुनाव विक्टोरियामेट्रिक्स पर पड़ा; हम पैसे बचाना चाहते थे और हमने ऐसा किया।

आइए तुरंत दो बिंदु हटा दें - मेट्रिक्स अपलोड करना और संसाधनों की उच्च खपत। और हमें बस दो बिंदु तय करने हैं जो हमने अभी भी अपने लिए छोड़े हैं।

यहां मैं तुरंत आरक्षण कराऊंगा, हम विक्टोरियामेट्रिक्स को मेट्रिक्स का भंडारण मानते हैं। लेकिन चूंकि हम संभवतया पूरे लेरॉय के लिए विक्टोरियामेट्रिक्स को भंडारण के रूप में प्रदान करेंगे, इसलिए हमें उन लोगों को सीमित करने की आवश्यकता है जो इस क्लस्टर का उपयोग करेंगे ताकि वे इसे हमें न दें।

एक अद्भुत पैरामीटर है जो आपको समय, डेटा की मात्रा और निष्पादन समय के अनुसार सीमित करने की अनुमति देता है।

एक उत्कृष्ट विकल्प भी है जो हमें मेमोरी खपत को सीमित करने की अनुमति देता है, जिससे हम वही संतुलन पा सकते हैं जो हमें सामान्य ऑपरेटिंग गति और पर्याप्त संसाधन खपत प्राप्त करने की अनुमति देगा।

एक और बिंदु घटाएं, यानी बिंदु काट दें - आप मेमोरी खपत को सीमित नहीं कर सकते।

पहले पुनरावृत्तियों में, हमने विक्टोरियामेट्रिक्स सिंगल नोड का परीक्षण किया। इसके बाद हम विक्टोरियामेट्रिक्स क्लस्टर संस्करण पर आगे बढ़ते हैं।

यहां हमारे पास विक्टोरियामेट्रिक्स में अलग-अलग सेवाओं को अलग करने की खुली छूट है, यह इस बात पर निर्भर करता है कि वे किस पर चलेंगी और किन संसाधनों का उपभोग करेंगी। यह एक बहुत ही लचीला और सुविधाजनक समाधान है. हमने खुद पर इसका प्रयोग किया.

विक्टोरियामेट्रिक्स क्लस्टर संस्करण के मुख्य घटक vmstsorage हैं। इनका N नंबर हो सकता है. हमारे मामले में अब तक उनमें से 2 हैं।

और वहाँ vminsert है। यह एक प्रॉक्सी सर्वर है जो हमें अनुमति देता है: उन सभी स्टोरेज के बीच शार्डिंग की व्यवस्था करें जिनके बारे में हमने बताया था, और यह एक प्रतिकृति की भी अनुमति देता है, यानी आपके पास शार्डिंग और एक प्रतिकृति दोनों होगी।

Vminsert प्रोमेथियस से OpenTSDB, ग्रेफाइट, इन्फ्लक्सDB और रिमोटराइट प्रोटोकॉल का समर्थन करता है।

इसमें वीएमसेलेक्ट भी है। इसका मुख्य कार्य vmstorage पर जाना, उनसे डेटा प्राप्त करना, इस डेटा को डीडुप्लिकेट करना और क्लाइंट को देना है।

Vmagent नाम की एक अद्भुत चीज़ है। हम वास्तव में उसे पसंद करते हैं। यह आपको बिल्कुल प्रोमेथियस की तरह कॉन्फ़िगर करने की अनुमति देता है और फिर भी प्रोमेथियस की तरह ही सब कुछ करता है। अर्थात्, यह विभिन्न संस्थाओं और सेवाओं से मेट्रिक्स एकत्र करता है और उन्हें vminsert पर भेजता है। फिर सब कुछ आप पर निर्भर करता है.

एक और बेहतरीन सेवा vmalert है, जो आपको विक्टोरियामेट्रिक्स को बैकएंड के रूप में उपयोग करने, vminsert से संसाधित डेटा प्राप्त करने और इसे vmselect पर भेजने की अनुमति देती है। यह अलर्ट के साथ-साथ नियमों को भी स्वयं संसाधित करता है। अलर्ट के मामले में, हम अलर्टमैनेजर के माध्यम से अलर्ट प्राप्त करते हैं।

एक wmauth घटक है. हम इसे क्लस्टर के मल्टीटेनेंसी संस्करण के लिए एक प्राधिकरण प्रणाली के रूप में उपयोग कर सकते हैं या नहीं (हमने अभी तक इस पर निर्णय नहीं लिया है)। यह प्रोमेथियस के लिए रिमोटराइट का समर्थन करता है और यूआरएल, या इसके दूसरे भाग के आधार पर अधिकृत कर सकता है, जहां आप लिख सकते हैं या नहीं लिख सकते हैं।

इसमें vmbackup, vmrestore भी है। यह, संक्षेप में, सभी डेटा की बहाली और बैकअप है। S3, GCS, फ़ाइल कर सकते हैं।

हमारे क्लस्टर का पहला पुनरावृत्ति संगरोध के दौरान किया गया था। उस समय, कोई प्रतिकृति नहीं थी, इसलिए हमारे पुनरावृत्ति में दो अलग-अलग और स्वतंत्र क्लस्टर शामिल थे जिनमें हमें रिमोटवाइट के माध्यम से डेटा प्राप्त होता था।

यहां मैं एक आरक्षण करूंगा कि जब हमने विक्टोरियामेट्रिक्स सिंगल नोड से विक्टोरियामेट्रिक्स क्लस्टर संस्करण पर स्विच किया, तब भी हमारे पास वही उपभोग किए गए संसाधन बने रहे, यानी मुख्य एक मेमोरी है। हमारा डेटा, यानी संसाधन खपत, लगभग इसी तरह वितरित किया गया था।

यहां एक प्रतिकृति पहले ही जोड़ी जा चुकी है. हमने इन सभी को एक अपेक्षाकृत बड़े क्लस्टर में जोड़ दिया। हमारा सारा डेटा साझा और प्रतिकृति दोनों है।

पूरे क्लस्टर में N प्रवेश बिंदु हैं, यानी प्रोमेथियस HAPROXY के माध्यम से डेटा जोड़ सकता है। यहां हमारे पास यह प्रवेश बिंदु है। और इस प्रवेश बिंदु के माध्यम से आप ग्राफाना से लॉग इन कर सकते हैं।

हमारे मामले में, HAPROXY एकमात्र पोर्ट है जो प्रॉक्सी इस क्लस्टर के अंदर अन्य सेवाओं का चयन, सम्मिलित और अन्य करता है। हमारे मामले में, एक पता बनाना असंभव था; हमें कई प्रवेश बिंदु बनाने पड़े, क्योंकि वर्चुअल मशीनें जिन पर विक्टोरियामेट्रिक्स क्लस्टर चलता है, वे एक ही क्लाउड प्रदाता के विभिन्न क्षेत्रों में स्थित हैं, यानी हमारे क्लाउड के अंदर नहीं, बल्कि बाहर .

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

शाश्वत प्रश्न: "निगरानी की निगरानी कौन करता है?" हमारे मामले में, मॉनिटरिंग मॉनिटर स्वयं की निगरानी करता है, क्योंकि हम प्रत्येक नोड पर vmagent का उपयोग करते हैं। और चूंकि हमारे नोड्स एक ही प्रदाता के विभिन्न डेटा केंद्रों में वितरित किए जाते हैं, प्रत्येक डेटा केंद्र का अपना चैनल होता है, वे स्वतंत्र होते हैं, और यदि एक विभाजित मस्तिष्क आता है, तब भी हमें अलर्ट प्राप्त होंगे। हां, इनकी संख्या अधिक होगी, लेकिन किसी की तुलना में अधिक अलर्ट प्राप्त करना बेहतर है।

हम अपनी सूची HA कार्यान्वयन के साथ समाप्त करते हैं।

और आगे मैं विक्टोरियामेट्रिक्स समुदाय के साथ संवाद करने के अनुभव को नोट करना चाहूंगा। यह बहुत सकारात्मक निकला. लोग प्रतिक्रियाशील हैं. वे पेश किए जाने वाले प्रत्येक मामले की गहराई से जांच करने का प्रयास करते हैं।

मैंने GitHub पर मुद्दे शुरू किए। उनका बहुत जल्द समाधान किया गया. कुछ और मुद्दे हैं जो पूरी तरह से बंद नहीं हुए हैं, लेकिन मैं पहले से ही कोड से देख सकता हूं कि इस दिशा में काम चल रहा है।

पुनरावृत्तियों के दौरान मेरे लिए मुख्य पीड़ा यह थी कि यदि मैं एक नोड बंद कर देता हूं, तो पहले 30 सेकंड के लिए vminsert समझ नहीं पाता कि कोई बैकएंड नहीं था। ये अब तय हो गया है. और सचमुच एक या दो सेकंड में, डेटा सभी शेष नोड्स से लिया जाता है, और अनुरोध उस लापता नोड की प्रतीक्षा करना बंद कर देता है।

किसी समय हम चाहते थे कि विक्टोरियामेट्रिक्स विक्टोरियामेट्रिक्स ऑपरेटर बने। हमने उसका इंतजार किया. अब हम सक्रिय रूप से विक्टोरियामेट्रिक्स ऑपरेटर के लिए सभी पूर्व-गणना नियमों आदि प्रोमेथियस को लेने के लिए एक रूपरेखा का निर्माण कर रहे हैं, क्योंकि हम प्रोमेथियस ऑपरेटर के साथ आने वाले नियमों का काफी सक्रिय रूप से उपयोग कर रहे हैं।

क्लस्टर कार्यान्वयन में सुधार के प्रस्ताव हैं। मैंने उन्हें ऊपर रेखांकित किया है।

और मैं वास्तव में डाउनसैंपलिंग करना चाहता हूं। हमारे मामले में, रुझान देखने के लिए विशेष रूप से डाउनसैंपलिंग की आवश्यकता होती है। मोटे तौर पर कहें तो दिन भर में मेरे लिए एक मीट्रिक ही काफी है। ये रुझान एक साल, तीन, पांच, दस साल के लिए जरूरी हैं। और एक मीट्रिक मान काफी है.

• प्रोमेथियस का उपयोग करते समय, हमने दर्द को जाना है, जैसा कि हमारे कुछ सहयोगियों ने भी किया है।
• हमने अपने लिए विक्टोरियामेट्रिक्स को चुना।
• यह लंबवत और क्षैतिज रूप से काफी अच्छी तरह से स्केल करता है।
• हम क्लस्टर में विभिन्न घटकों को अलग-अलग संख्या में नोड्स में वितरित कर सकते हैं, उन्हें मेमोरी द्वारा सीमित कर सकते हैं, मेमोरी जोड़ सकते हैं, आदि।

हम घर पर विक्टोरियामेट्रिक्स का उपयोग करेंगे क्योंकि हमें यह वास्तव में पसंद आया। यही था और जो हो गया है.

https://t.me/VictoriaMetrics_ru1

विक्टोरियामेट्रिक्स चैट, मेरे संपर्क, लेरॉयमर्लिन तकनीकी रडार के लिए कुछ क्यूआर कोड।

स्रोत: www.habr.com