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

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

ग्रेफाइट+व्हिस्पर समस्याएँ

1. डिस्क सबसिस्टम पर उच्च भार

परिवर्तन के समय, प्रति मिनट लगभग 1.5 मिलियन मेट्रिक्स हमारे पास आ रहे थे। ऐसे प्रवाह के साथ, सर्वर पर डिस्क का उपयोग ~30% था। सामान्य तौर पर, यह काफी स्वीकार्य था - सब कुछ स्थिर रूप से काम करता था, जल्दी से लिखा गया था, जल्दी से पढ़ा गया... जब तक कि विकास टीमों में से एक ने एक नई सुविधा शुरू नहीं की और हमें प्रति मिनट 10 मिलियन मीट्रिक भेजना शुरू नहीं किया। तभी डिस्क सबसिस्टम मजबूत हुआ और हमने 100% उपयोग देखा। समस्या का शीघ्र समाधान हो गया, लेकिन अवशेष रह गया।

2. प्रतिकृति और निरंतरता का अभाव

सबसे अधिक संभावना है, ग्रेफाइट+व्हिस्पर का उपयोग/इस्तेमाल करने वाले हर किसी की तरह, हमने दोष सहनशीलता बनाने के लिए एक साथ कई ग्रेफाइट सर्वरों पर मेट्रिक्स की एक ही धारा डाली। और इसमें कोई विशेष समस्या नहीं थी - उस क्षण तक जब सर्वरों में से एक किसी कारण से क्रैश हो गया। कभी-कभी हम किसी गिरे हुए सर्वर को तुरंत उठाने में कामयाब हो जाते थे, और कार्बन-सी-रिले उसके कैश से मेट्रिक्स को उसमें लोड करने में कामयाब हो जाता था, लेकिन कभी-कभी नहीं। और फिर मेट्रिक्स में एक छेद था, जिसे हमने rsync से भर दिया। यह प्रक्रिया काफी लंबी थी. एकमात्र राहत की बात यह थी कि ऐसा बहुत कम होता था। हमने समय-समय पर मेट्रिक्स का एक यादृच्छिक सेट भी लिया और क्लस्टर के पड़ोसी नोड्स पर उसी प्रकार के अन्य लोगों के साथ उनकी तुलना की। लगभग 5% मामलों में, कई मान भिन्न थे, जिनसे हम बहुत खुश नहीं थे।

3. बड़े पदचिह्न

चूंकि हम ग्रेफाइट में न केवल बुनियादी ढांचे, बल्कि व्यावसायिक मेट्रिक्स (और अब कुबेरनेट्स से मेट्रिक्स भी) लिखते हैं, हमें अक्सर ऐसी स्थिति मिलती है जिसमें मीट्रिक में केवल कुछ मान होते हैं, और .wsp फ़ाइल सभी प्रतिधारण को ध्यान में रखते हुए बनाई जाती है अवधि, और पूर्व-आवंटित जगह लेता है, जो हमारे लिए ~2एमबी थी। समस्या इस तथ्य से और भी बढ़ जाती है कि समय के साथ बहुत सारी समान फ़ाइलें सामने आती हैं, और उन पर रिपोर्ट बनाते समय, खाली बिंदुओं को पढ़ने में बहुत समय और संसाधन लगते हैं।

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

उपरोक्त सभी का होना (पिछले को ध्यान में रखते हुए)। लेख), साथ ही प्राप्त मेट्रिक्स की संख्या में निरंतर वृद्धि, सभी मेट्रिक्स को 30 सेकंड के भंडारण अंतराल में स्थानांतरित करने की इच्छा। (यदि आवश्यक हो तो 10 सेकंड तक), हमने व्हिस्पर के एक आशाजनक विकल्प के रूप में ग्रेफाइट+क्लिकहाउस को आज़माने का निर्णय लिया।

ग्रेफाइट+क्लिकहाउस। अपेक्षाएं

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

मैं निम्नलिखित प्राप्त करना चाहूँगा:

डिस्क सबसिस्टम उपयोग को 30% से घटाकर 5% करना;
स्थान की मात्रा को 1TB से घटाकर 100GB कर दें;
सर्वर में प्रति मिनट 100 मिलियन मेट्रिक्स प्राप्त करने में सक्षम हो;
बॉक्स से बाहर डेटा प्रतिकृति और दोष सहनशीलता;
इस परियोजना पर एक वर्ष तक न बैठे रहें और उचित समय सीमा के भीतर परिवर्तन करें;
बिना डाउनटाइम के स्विच करें।

काफी महत्वाकांक्षी, है ना?

ग्रेफाइट+क्लिकहाउस। अवयव

ग्रेफाइट प्रोटोकॉल के माध्यम से डेटा प्राप्त करने और बाद में इसे ClickHouse में रिकॉर्ड करने के लिए, मैंने चयन किया कार्बन-क्लिकहाउस (गोलंग)।

ClickHouse की नवीनतम रिलीज़, स्थिर संस्करण 1.1.54253, को समय श्रृंखला संग्रहीत करने के लिए डेटाबेस के रूप में चुना गया था। इसके साथ काम करते समय समस्याएँ थीं: लॉग में त्रुटियों का पहाड़ भर गया था, और यह पूरी तरह से स्पष्ट नहीं था कि उनके साथ क्या किया जाए। के साथ चर्चा में रोमन लोमोनोसोव (कार्बन-क्लिकहाउस, ग्रेफाइट-क्लिकहाउस और कई अन्य के लेखक) पुराने को चुना गया था रिलीज़ 1.1.54236. त्रुटियाँ गायब हो गईं - सब कुछ धमाके के साथ काम करने लगा।

ClickHouse से डेटा पढ़ने के लिए चयनित ग्रेफाइट-स्लिकहाउस (गोलंग)। ग्रेफाइट के लिए एक एपीआई के रूप में - कार्बोनेपी (गोलंग)। क्लिकहाउस का उपयोग तालिकाओं के बीच प्रतिकृति को व्यवस्थित करने के लिए किया गया था चिड़ियाघर संचालक. रूटिंग मेट्रिक्स के लिए, हमने अपने प्रिय को छोड़ दिया कार्बन-सी-रिले (सी) (पिछला लेख देखें).

ग्रेफाइट+क्लिकहाउस। टेबल संरचना

"ग्रेफाइट" एक डेटाबेस है जिसे हमने मॉनिटरिंग टेबल के लिए बनाया है।

"ग्राफाइट.मेट्रिक्स" - रेप्लिकेटेडरिप्लेसिंगमर्जट्री इंजन वाली तालिका (प्रतिकृति)। मर्जट्री को बदलना). यह तालिका मेट्रिक्स के नाम और उनके पथ संग्रहीत करती है।

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"ग्राफाइट.डेटा" - रेप्लिकेटेडग्रेफाइटमर्जट्री इंजन वाली तालिका (प्रतिकृति)। ग्रेफाइटमर्जट्री). यह तालिका मीट्रिक मान संग्रहीत करती है.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

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

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"ग्राफाइट.डेटा_स्टैट" - रिप्लिकेटेडएग्रीगेटिंगमर्जट्री इंजन (प्रतिकृति) के साथ शर्त के अनुसार भरी गई एक तालिका एग्रीगेटिंगमर्जट्री). यह तालिका आने वाले मेट्रिक्स की संख्या को रिकॉर्ड करती है, जो 4 नेस्टिंग स्तरों तक विभाजित है।

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

ग्रेफाइट+क्लिकहाउस। घटक इंटरैक्शन आरेख

ग्रेफाइट+क्लिकहाउस। आंकड़ों का विस्थापन

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

ClickHouse तालिकाओं की प्रतिकृति में भाग लेने वाले सर्वरों में से एक के कार्बन-क्लिकहाउस में मेट्रिक्स की एक अतिरिक्त स्ट्रीम भेजने के लिए कार्बन-सी-रिले में एक नियम जोड़ा गया है।
हमने पायथन में एक छोटी सी स्क्रिप्ट लिखी, जो व्हिस्पर-डंप लाइब्रेरी का उपयोग करते हुए, हमारे स्टोरेज से सभी .wsp फ़ाइलों को पढ़ती है और इस डेटा को 24 थ्रेड्स में ऊपर वर्णित कार्बन-क्लिकहाउस में भेजती है। कार्बन-क्लिकहाउस में स्वीकृत मीट्रिक मानों की संख्या 125 मिलियन/मिनट तक पहुंच गई, और क्लिकहाउस को जरा भी पसीना नहीं आया।
हमने मौजूदा डैशबोर्ड में उपयोग किए गए फ़ंक्शंस को डीबग करने के लिए ग्राफाना में एक अलग डेटासोर्स बनाया है। हमने उन फ़ंक्शंस की एक सूची की पहचान की जिनका हमने उपयोग किया था, लेकिन उन्हें कार्बनएपीआई में लागू नहीं किया गया था। हमने इन कार्यों को जोड़ा और कार्बनएपि के लेखकों को पीआर भेजे (उन्हें विशेष धन्यवाद)।
बैलेंसर सेटिंग्स में रीडिंग लोड को स्विच करने के लिए, हमने एंडपॉइंट को ग्रेफाइट-एपीआई (ग्रेफाइट+व्हिस्पर के लिए एपीआई इंटरफ़ेस) से कार्बनएपीआई में बदल दिया।

ग्रेफाइट+क्लिकहाउस। परिणाम

डिस्क सबसिस्टम उपयोग को 30% से घटाकर 1% कर दिया गया;
स्थान की मात्रा को 1 टीबी से घटाकर 300 जीबी कर दिया गया;
हमारे पास सर्वर में प्रति मिनट 125 मिलियन मेट्रिक्स प्राप्त करने की क्षमता है (माइग्रेशन के समय चरम पर);
सभी मेट्रिक्स को बत्तीस सेकंड के भंडारण अंतराल में स्थानांतरित कर दिया गया;
प्राप्त डेटा प्रतिकृति और दोष सहनशीलता;
डाउनटाइम के बिना स्विच किया गया;
सब कुछ पूरा करने में लगभग 7 सप्ताह लग गए।

ग्रेफाइट+क्लिकहाउस। समस्या

हमारे मामले में, कुछ कमियाँ थीं। परिवर्तन के बाद हमें इसी का सामना करना पड़ा।

ClickHouse हमेशा तुरंत कॉन्फ़िगरेशन को दोबारा नहीं पढ़ता है; कभी-कभी इसे रीबूट करने की आवश्यकता होती है। उदाहरण के लिए, क्लिकहाउस कॉन्फ़िगरेशन में ज़ूकीपर क्लस्टर के विवरण के मामले में, इसका उपयोग तब तक नहीं किया गया था जब तक कि क्लिकहाउस-सर्वर को रीबूट नहीं किया गया था।
बड़े ClickHouse अनुरोध पूरे नहीं हुए, इसलिए ग्रेफाइट-क्लिकहाउस में हमारी ClickHouse कनेक्शन स्ट्रिंग इस तरह दिखती है:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse अक्सर स्थिर रिलीज़ के नए संस्करण जारी करता है; उनमें आश्चर्य हो सकता है: सावधान रहें।
कुबेरनेट्स में गतिशील रूप से बनाए गए कंटेनर कम और यादृच्छिक जीवनकाल के साथ बड़ी संख्या में मेट्रिक्स भेजते हैं। ऐसे मेट्रिक्स के लिए बहुत सारे बिंदु नहीं हैं, और स्थान के साथ कोई समस्या नहीं है। लेकिन प्रश्न बनाते समय, ClickHouse 'मेट्रिक्स' तालिका से बड़ी संख्या में इन्हीं मैट्रिक्स को चुनता है। 90% मामलों में, विंडो (24 घंटे) से परे उन पर कोई डेटा नहीं है। लेकिन 'डेटा' तालिका में इस डेटा को खोजने में समय व्यतीत होता है, और अंततः टाइमआउट हो जाता है। इस समस्या को हल करने के लिए, हमने दिन के दौरान सामने आने वाले मेट्रिक्स की जानकारी के साथ एक अलग दृश्य बनाए रखना शुरू किया। इस प्रकार, गतिशील रूप से बनाए गए कंटेनरों के लिए रिपोर्ट (ग्राफ़) बनाते समय, हम केवल उन मेट्रिक्स को क्वेरी करते हैं जो किसी दिए गए विंडो के भीतर सामने आए थे, न कि पूरे समय के लिए, जिससे उन पर रिपोर्ट के निर्माण में काफी तेजी आई। ऊपर वर्णित समाधान के लिए, मैंने एकत्र किया ग्रेफाइट-क्लिकहाउस (कांटा), जिसमें date_metrics तालिका के साथ काम करने का कार्यान्वयन शामिल है।

ग्रेफाइट+क्लिकहाउस। टैग

संस्करण 1.1.0 के साथ ग्रेफाइट आधिकारिक हो गया समर्थन टैग. और हम सक्रिय रूप से इस बारे में सोच रहे हैं कि ग्रेफाइट+क्लिकहाउस स्टैक में इस पहल का समर्थन करने के लिए क्या और कैसे किया जाए।

ग्रेफाइट+क्लिकहाउस। विसंगति डिटेक्टर

ऊपर वर्णित बुनियादी ढांचे के आधार पर, हमने एक विसंगति डिटेक्टर का एक प्रोटोटाइप लागू किया है, और यह काम करता है! लेकिन उसके बारे में अगले लेख में।

सदस्यता लें, ऊपर तीर दबाएँ और खुश रहें!

स्रोत: www.habr.com

मेट्रिक्स भंडारण: हमने ग्रेफाइट+व्हिस्पर से ग्रेफाइट+क्लिकहाउस पर कैसे स्विच किया