एक सेवा के रूप में निगरानी: माइक्रोसर्विस आर्किटेक्चर के लिए एक मॉड्यूलर प्रणाली

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

यह पोस्ट हमारे साथ मेरे भाषण की प्रतिलेख है वर्गों आरआईटी++ पर। कई लोगों ने हमसे वहां से रिपोर्टों का टेक्स्ट संस्करण बनाने के लिए कहा। यदि आप सम्मेलन में थे या वीडियो देखा, तो आपको कुछ भी नया नहीं मिलेगा। और बाकी सभी - बिल्ली में आपका स्वागत है। मैं आपको बताऊंगा कि हम ऐसी प्रणाली तक कैसे पहुंचे, यह कैसे काम करती है और हम इसे कैसे अद्यतन करने की योजना बनाते हैं।

अतीत: योजनाएँ और योजनाएँ

हम वर्तमान निगरानी प्रणाली तक कैसे पहुंचे? इस सवाल का जवाब देने के लिए आपको 2015 में जाना होगा. तब यह ऐसा दिखता था:

हमारे पास लगभग 24 नोड थे जो निगरानी के लिए जिम्मेदार थे। अलग-अलग क्राउन, स्क्रिप्ट, डेमॉन का एक पूरा पैक है जो किसी तरह किसी चीज की निगरानी करता है, संदेश भेजता है और कार्य करता है। हमने सोचा कि हम जितना आगे बढ़ेंगे, ऐसी प्रणाली उतनी ही कम व्यवहार्य होगी। इसे विकसित करने का कोई मतलब नहीं है: यह बहुत बोझिल है।
हमने उन निगरानी तत्वों को चुनने का निर्णय लिया जिन्हें हम रखेंगे और विकसित करेंगे, और जिन्हें हम छोड़ देंगे। उनमें से 19 थे। डैशबोर्ड के रूप में केवल ग्रेफाइट्स, एग्रीगेटर्स और ग्राफाना ही बचे थे। लेकिन नई व्यवस्था कैसी दिखेगी? इस कदर:

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

मानक: निगरानी 2.0

2015 में योजनाएं ऐसी ही दिखती थीं। लेकिन हमें न केवल बुनियादी ढांचा और सेवा तैयार करनी थी, बल्कि इसके लिए दस्तावेज भी तैयार करने थे। हमने अपने लिए एक कॉर्पोरेट मानक विकसित किया है, जिसे हम मॉनिटरिंग 2.0 कहते हैं। सिस्टम के लिए क्या आवश्यकताएँ थीं?

• निरंतर उपलब्धता;
• मेट्रिक्स भंडारण अंतराल = 10 सेकंड;
• मेट्रिक्स और डैशबोर्ड का संरचित भंडारण;
• एसएलए > 99,99%
• यूडीपी (!) के माध्यम से इवेंट मेट्रिक्स का संग्रह।

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

प्रत्येक उपसर्ग में कुछ गुण होते हैं। सर्वर, नेटवर्क, कंटेनर, संसाधन, एप्लिकेशन इत्यादि के लिए मेट्रिक्स हैं। स्पष्ट, सख्त, टाइप की गई फ़िल्टरिंग लागू की गई है, जहां हम प्रथम-स्तरीय मेट्रिक्स को स्वीकार करते हैं और बाकी को छोड़ देते हैं। इस तरह हमने 2015 में इस प्रणाली की योजना बनाई। वर्तमान में क्या है?

वर्तमान: निगरानी घटकों की परस्पर क्रिया का आरेख

सबसे पहले, हम अनुप्रयोगों की निगरानी करते हैं: हमारा PHP कोड, एप्लिकेशन और माइक्रोसर्विसेज - संक्षेप में, वह सब कुछ जो हमारे डेवलपर्स लिखते हैं। सभी एप्लिकेशन यूडीपी के माध्यम से ब्रुबेक एग्रीगेटर को मेट्रिक्स भेजते हैं (आंकड़े, सी में फिर से लिखे गए)। सिंथेटिक परीक्षणों में यह सबसे तेज़ निकला। और यह पहले से एकत्रित मेट्रिक्स को टीसीपी के माध्यम से ग्रेफाइट को भेजता है।

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

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

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

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

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

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

हमने कुबेरनेट्स में मोइरा को तैनात किया; यह मुख्य डेटाबेस के रूप में रेडिस सर्वर के क्लस्टर का उपयोग करता है। परिणाम एक दोष-सहिष्णु प्रणाली थी। यह मेट्रिक्स की स्ट्रीम की तुलना ट्रिगर्स की सूची से करता है: यदि इसमें कोई उल्लेख नहीं है, तो यह मेट्रिक को छोड़ देता है। इसलिए यह प्रति मिनट गीगाबाइट मेट्रिक्स को पचाने में सक्षम है।

हमने इसमें एक कॉर्पोरेट एलडीएपी भी संलग्न किया है, जिसकी मदद से कॉर्पोरेट सिस्टम का प्रत्येक उपयोगकर्ता मौजूदा (या नए बनाए गए) ट्रिगर्स के आधार पर अपने लिए सूचनाएं बना सकता है। चूँकि मोइरा में ग्रेफाइट है, यह इसकी सभी विशेषताओं का समर्थन करता है। तो आप सबसे पहले लाइन लें और उसे ग्राफाना में कॉपी करें। देखें कि डेटा ग्राफ़ पर कैसे प्रदर्शित होता है। और फिर आप वही पंक्ति लें और उसे मोइरा में कॉपी करें। आप इसे सीमा के साथ लटकाते हैं और आउटपुट पर अलर्ट प्राप्त करते हैं। यह सब करने के लिए आपको किसी विशेष ज्ञान की आवश्यकता नहीं है। मोइरा एसएमएस, ईमेल, जिरा, स्लैक के माध्यम से अलर्ट कर सकता है... यह कस्टम स्क्रिप्ट के निष्पादन का भी समर्थन करता है। जब उसके साथ कोई ट्रिगर होता है, और वह एक कस्टम स्क्रिप्ट या बाइनरी की सदस्यता लेती है, तो वह इसे चलाती है और इस बाइनरी के लिए JSON को stdin पर भेजती है। तदनुसार, आपके प्रोग्राम को इसे पार्स करना होगा। आप इस JSON के साथ क्या करेंगे यह आप पर निर्भर है। आप चाहें तो टेलीग्राम पर भेज दें, चाहें तो जीरा में टास्क खोल लें, कुछ भी कर लें।

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

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

निगरानी घटक

इस कार्य के लिए हमारे द्वारा उपयोग किए गए घटकों के लिंक की एक सूची यहां दी गई है। ये सभी खुले स्रोत हैं.

ग्रेफाइट:

• गो-कार्बन: github.com/lomik/go-कार्बन
• फुसफुसाना: github.com/graphite-project/whisper
• ग्रेफाइट-एपीआई: github.com/brutasse/graphite-api

कार्बन-सी-रिले:

github.com/grobian/Carbon-c-relay

ब्रुबेक:

github.com/github/brubeck

एकत्रित:

Collectd.org

मोइरा:

github.com/moira-alert

ग्राफाना:

grafana.com

हीप्स्टर:

github.com/kubernetes/heapster

सांख्यिकी

और यहां कुछ आंकड़े दिए गए हैं कि सिस्टम हमारे लिए कैसे काम करता है।

एग्रीगेटर (ब्रुबेक)

मेट्रिक्स की संख्या: ~300/सेकंड
ग्रेफाइट को मेट्रिक्स भेजने का अंतराल: 30 सेकंड
सर्वर संसाधन उपयोग: ~ 6% सीपीयू (हम पूर्ण सर्वर के बारे में बात कर रहे हैं); ~ 1 जीबी रैम; ~3 एमबीपीएस लैन

ग्रेफाइट (गो-कार्बन)

मेट्रिक्स की संख्या: ~ 1/मिनट
मेट्रिक्स अद्यतन अंतराल: 30 सेकंड
मेट्रिक्स भंडारण योजना: 30 सेकंड 35 दिन, 5 मिनट 90 दिन, 10 मिनट 365 दिन (आपको यह समझ देता है कि लंबी अवधि में सेवा का क्या होता है)
सर्वर संसाधन उपयोग: ~10% सीपीयू; ~ 20 जीबी रैम; ~30 एमबीपीएस लैन

लचीलापन

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

यहां एक वास्तविक समस्या का उदाहरण दिया गया है. ग्रेफाइट में एक मीट्रिक एक फ़ाइल है। इसका एक नाम है. फ़ाइल का नाम = मीट्रिक नाम. और वहां पहुंचने का एक रास्ता है. Linux में फ़ाइल नाम 255 वर्णों तक सीमित हैं। और हमारे पास ("आंतरिक ग्राहकों" के रूप में) डेटाबेस विभाग के लोग हैं। वे हमें बताते हैं: “हम अपनी एसक्यूएल क्वेरीज़ की निगरानी करना चाहते हैं। और वे 255 अक्षर नहीं, बल्कि 8 एमबी के हैं। हम उन्हें ग्राफाना में प्रदर्शित करना चाहते हैं, इस अनुरोध के पैरामीटर देखना चाहते हैं, और इससे भी बेहतर, हम ऐसे अनुरोधों का शीर्ष देखना चाहते हैं। यदि इसे वास्तविक समय में प्रदर्शित किया जाए तो यह बहुत अच्छा होगा। उन्हें सचेत करना वाकई अच्छा होगा।''

उदाहरण के रूप में SQL क्वेरी का उदाहरण लिया गया है साइट postgrespro.ru

हम एक रेडिस सर्वर स्थापित करते हैं और अपने कलेक्टेड प्लगइन्स का उपयोग करते हैं, जो पोस्टग्रेज पर जाते हैं और वहां से सारा डेटा लेते हैं, मेट्रिक्स को ग्रेफाइट में भेजते हैं। लेकिन हम मीट्रिक नाम को हैश से बदल देते हैं। हम एक साथ एक ही हैश को कुंजी के रूप में Redis और संपूर्ण SQL क्वेरी को एक मान के रूप में भेजते हैं। हमें बस यह सुनिश्चित करना है कि ग्राफाना रेडिस में जा सके और यह जानकारी ले सके। हम ग्रेफाइट एपीआई खोल रहे हैं क्योंकि... यह ग्रेफाइट के साथ सभी निगरानी घटकों की बातचीत के लिए मुख्य इंटरफ़ेस है, और हम वहां एक नया फ़ंक्शन दर्ज करते हैं जिसे उपनामबायहैश () कहा जाता है - ग्राफाना से हमें मीट्रिक का नाम मिलता है, और इसे रेडिस के अनुरोध में एक कुंजी के रूप में उपयोग करते हैं। प्रतिक्रिया से हमें कुंजी का मान मिलता है, जो हमारी "एसक्यूएल क्वेरी" है। इस प्रकार, हमने ग्राफाना में एक एसक्यूएल क्वेरी का प्रदर्शन प्रदर्शित किया, जिसे सैद्धांतिक रूप से वहां प्रदर्शित करना असंभव था, साथ ही उस पर आंकड़े (कॉल, पंक्तियां, कुल_समय, ...) भी।

परिणाम

उपलब्धता। हमारी निगरानी सेवा किसी भी एप्लिकेशन और किसी भी कोड से 24/7 उपलब्ध है। यदि आपके पास भंडारण सुविधाओं तक पहुंच है, तो आप सेवा में डेटा लिख ​​सकते हैं। भाषा महत्वपूर्ण नहीं है, निर्णय महत्वपूर्ण नहीं हैं. आपको केवल यह जानना होगा कि सॉकेट कैसे खोलें, वहां एक मीट्रिक कैसे डालें और सॉकेट को कैसे बंद करें।

विश्वसनीयता। सभी घटक दोष-सहिष्णु हैं और हमारे भार को अच्छी तरह से संभालते हैं।

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

आजादी। आप DevOps इंजीनियरों की सहायता के बिना, यह सब स्वयं कर सकते हैं। और यह एक फायदा है, क्योंकि आप अभी अपने प्रोजेक्ट की निगरानी कर सकते हैं, आपको किसी से पूछने की ज़रूरत नहीं है - या तो काम शुरू करने के लिए या बदलाव करने के लिए।

हमारा लक्ष्य क्या है?

नीचे सूचीबद्ध हर चीज़ केवल अमूर्त विचार नहीं है, बल्कि कुछ ऐसी चीज़ है जिसकी ओर कम से कम पहला कदम उठाया गया है।

1. विसंगति डिटेक्टर। हम एक ऐसी सेवा बनाना चाहते हैं जो हमारे ग्रेफाइट स्टोरेज में जाएगी और विभिन्न एल्गोरिदम का उपयोग करके प्रत्येक मीट्रिक की जांच करेगी। पहले से ही एल्गोरिदम हैं जिन्हें हम देखना चाहते हैं, डेटा है, हम जानते हैं कि इसके साथ कैसे काम करना है।
2. मेटाडेटा. हमारे पास कई सेवाएँ हैं, वे समय के साथ बदलती हैं, ठीक उनके साथ काम करने वाले लोगों की तरह। दस्तावेज़ीकरण को लगातार मैन्युअल रूप से बनाए रखना कोई विकल्प नहीं है। इसीलिए अब हम मेटाडेटा को अपनी माइक्रोसर्विसेज में एम्बेड कर रहे हैं। इसमें बताया गया है कि इसे किसने विकसित किया, यह किन भाषाओं के साथ इंटरैक्ट करता है, एसएलए आवश्यकताएं, सूचनाएं कहां और किसे भेजी जानी चाहिए। किसी सेवा को तैनात करते समय, सभी इकाई डेटा स्वतंत्र रूप से बनाया जाता है। परिणामस्वरूप, आपको दो लिंक मिलते हैं - एक ट्रिगर्स के लिए, दूसरा ग्राफाना में डैशबोर्ड के लिए।
3. हर घर में निगरानी. हमारा मानना ​​है कि सभी डेवलपर्स को ऐसी प्रणाली का उपयोग करना चाहिए। इस मामले में, आप हमेशा समझते हैं कि आपका ट्रैफ़िक कहां है, उसका क्या होता है, वह कहां गिरता है, उसकी कमजोरियां कहां हैं। यदि, उदाहरण के लिए, कोई चीज़ आती है और आपकी सेवा को क्रैश कर देती है, तो आपको इसके बारे में प्रबंधक से कॉल के दौरान नहीं, बल्कि अलर्ट से पता चलेगा, और आप तुरंत नवीनतम लॉग खोल सकते हैं और देख सकते हैं कि वहां क्या हुआ था।
4. उच्च प्रदर्शन। हमारा प्रोजेक्ट लगातार बढ़ रहा है, और आज यह प्रति मिनट लगभग 2 मीट्रिक मान संसाधित करता है। एक साल पहले, यह आंकड़ा 000 था। और वृद्धि जारी है, और इसका मतलब है कि कुछ समय बाद ग्रेफाइट (व्हिस्पर) डिस्क सबसिस्टम पर भारी लोड करना शुरू कर देगा। जैसा कि मैंने पहले ही कहा, घटकों की विनिमेयता के कारण यह निगरानी प्रणाली काफी सार्वभौमिक है। कोई व्यक्ति विशेष रूप से ग्रेफाइट के लिए अपने बुनियादी ढांचे का रखरखाव और लगातार विस्तार करता है, लेकिन हमने एक अलग मार्ग अपनाने का फैसला किया: उपयोग क्लिकहाउस हमारे मेट्रिक्स के लिए एक भंडार के रूप में। यह परिवर्तन लगभग पूरा हो चुका है, और बहुत जल्द मैं आपको और अधिक विस्तार से बताऊंगा कि यह कैसे किया गया: क्या कठिनाइयाँ थीं और उन्हें कैसे दूर किया गया, माइग्रेशन प्रक्रिया कैसे हुई, मैं बाइंडिंग के रूप में चुने गए घटकों और उनके कॉन्फ़िगरेशन का वर्णन करूंगा।

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

स्रोत: www.habr.com