बायोइनो - वितरित, स्केलेबल मेट्रिक्स एग्रीगेटर

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

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

दावा 1. प्रोजेक्ट के डेवलपर जीथब ने इसका समर्थन करना बंद कर दिया: पैच और फिक्स प्रकाशित करना, हमारे और (केवल हमारे ही नहीं) पीआर को स्वीकार करना। पिछले कुछ महीनों में (फरवरी-मार्च 2018 से कहीं), गतिविधि फिर से शुरू हो गई है, लेकिन उससे पहले लगभग 2 साल तक पूरी तरह शांति थी। इसके अलावा, परियोजना विकसित की जा रही है आंतरिक गिहब आवश्यकताओं के लिए, जो नई सुविधाओं की शुरूआत में एक गंभीर बाधा बन सकता है।

दावा 2. गणना की सटीकता. ब्रुबेक एकत्रीकरण के लिए कुल 65536 मान एकत्र करता है। हमारे मामले में, कुछ मैट्रिक्स के लिए, एकत्रीकरण अवधि (30 सेकंड) के दौरान, बहुत अधिक मान आ सकते हैं (चरम पर 1)। इस नमूने के परिणामस्वरूप, अधिकतम और न्यूनतम मान बेकार दिखाई देते हैं। उदाहरण के लिए, इस तरह:

जैसे थे

यह कैसा होना चाहिए था

इसी कारण से, रकम की गणना आम तौर पर गलत तरीके से की जाती है। यहां 32-बिट फ्लोट ओवरफ़्लो के साथ एक बग जोड़ें, जो आम तौर पर एक प्रतीत होता है कि निर्दोष मीट्रिक प्राप्त करते समय सर्वर को सेगफॉल्ट पर भेजता है, और सब कुछ बढ़िया हो जाता है। वैसे, बग को ठीक नहीं किया गया है।

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

सबसे पहले, गलती सहनशीलता, ताकि सर्वर पर अचानक कोई समस्या कार्यालय में एक मनोरोग ज़ोंबी सर्वनाश का कारण न बने। दूसरे, 4 मिलियन से अधिक एमपीएस को स्वीकार करने में सक्षम होने के लिए स्केलिंग, लिनक्स नेटवर्क स्टैक में गहरी खुदाई किए बिना और आवश्यक आकार में "चौड़ाई में" शांति से बढ़ रही है।

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

यदि आप समस्या के बारे में थोड़ा सोचते हैं और साथ ही फावड़े से बर्फ खोदते हैं, तो निम्नलिखित स्पष्ट विचार दिमाग में आ सकता है: आपको एक सांख्यिकीविद् की आवश्यकता है जो वितरित मोड में काम कर सके। अर्थात्, वह जो समय और मेट्रिक्स में नोड्स के बीच सिंक्रनाइज़ेशन लागू करता है। "बेशक, ऐसा समाधान शायद पहले से ही मौजूद है," हमने कहा और Google के पास गए... और उन्हें कुछ नहीं मिला. विभिन्न आँकड़ों के लिए दस्तावेज़ीकरण से गुजरने के बाद (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 दिसंबर, XNUMX तक) हमें बिल्कुल कुछ नहीं मिला। जाहिरा तौर पर, न तो डेवलपर्स और न ही इन समाधानों के उपयोगकर्ताओं को अभी तक इतने सारे मेट्रिक्स का सामना करना पड़ा है, अन्यथा वे निश्चित रूप से कुछ न कुछ लेकर आते।

और फिर हमें "खिलौना" स्टेट्सडी - बायोयिनो के बारे में याद आया, जो जस्ट फॉर फन हैकथॉन में लिखा गया था (प्रोजेक्ट का नाम हैकथॉन की शुरुआत से पहले स्क्रिप्ट द्वारा उत्पन्न किया गया था) और हमें एहसास हुआ कि हमें तत्काल अपने स्वयं के स्टेट्सडी की आवश्यकता है। किस लिए?

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

किस पर लिखें? बेशक, जंग में. क्यों?

• क्योंकि पहले से ही एक प्रोटोटाइप समाधान मौजूद था,
• क्योंकि लेख का लेखक उस समय पहले से ही रस्ट को जानता था और इसे ओपन-सोर्स में डालने के अवसर के साथ उत्पादन के लिए इसमें कुछ लिखने के लिए उत्सुक था,
• क्योंकि प्राप्त ट्रैफ़िक की प्रकृति (लगभग वास्तविक समय) के कारण GC वाली भाषाएँ हमारे लिए उपयुक्त नहीं हैं और GC ठहराव व्यावहारिक रूप से अस्वीकार्य हैं,
• क्योंकि आपको C के तुलनीय अधिकतम प्रदर्शन की आवश्यकता है
• क्योंकि रस्ट हमें निर्भय समवर्तीता प्रदान करता है, और यदि हमने इसे C/C++ में लिखना शुरू किया होता, तो हम ब्रुबेक की तुलना में और भी अधिक कमजोरियों, बफर ओवरफ्लो, दौड़ की स्थिति और अन्य डरावने शब्दों में फंस जाते।

रस्ट के ख़िलाफ़ भी बहस हुई. कंपनी को रस्ट में प्रोजेक्ट बनाने का कोई अनुभव नहीं था और अब हम इसे मुख्य प्रोजेक्ट में उपयोग करने की भी योजना नहीं बना रहे हैं। इसलिए, गंभीर आशंकाएं थीं कि कुछ भी काम नहीं आएगा, लेकिन हमने एक मौका लेने का फैसला किया और कोशिश की।

वक्त निकल गया...

अंततः, कई असफल प्रयासों के बाद, पहला कार्यशील संस्करण तैयार हो गया। क्या हुआ? यह हुआ था।

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

मेट्रिक्स वाले यूडीपी पैकेट एक साधारण राउंड रॉबिन के माध्यम से नेटवर्क उपकरण पर नोड्स के बीच असंतुलित होते हैं। बेशक, नेटवर्क हार्डवेयर पैकेटों की सामग्री को पार्स नहीं करता है और इसलिए प्रति सेकंड 4M से अधिक पैकेट खींच सकता है, मेट्रिक्स का उल्लेख नहीं करना जिसके बारे में वह कुछ भी नहीं जानता है। यदि हम इस बात को ध्यान में रखते हैं कि मेट्रिक्स प्रत्येक पैकेट में एक समय में एक नहीं आते हैं, तो हमें इस स्थान पर किसी भी प्रदर्शन समस्या की संभावना नहीं दिखती है। यदि कोई सर्वर क्रैश हो जाता है, तो नेटवर्क डिवाइस तुरंत (1-2 सेकंड के भीतर) इस तथ्य का पता लगाता है और क्रैश हुए सर्वर को रोटेशन से हटा देता है। इसके परिणामस्वरूप, निष्क्रिय (यानी, गैर-नेता) नोड्स को चार्ट पर गिरावट देखे बिना व्यावहारिक रूप से चालू और बंद किया जा सकता है। हम जो अधिकतम खो देते हैं वह अंतिम सेकंड में आए मेट्रिक्स का हिस्सा है। किसी लीडर की अचानक हानि/शटडाउन/स्विच अभी भी एक छोटी सी विसंगति पैदा करेगा (30 सेकंड का अंतराल अभी भी सिंक से बाहर है), लेकिन यदि नोड्स के बीच संचार है, तो इन समस्याओं को कम किया जा सकता है, उदाहरण के लिए, सिंक्रोनाइज़ेशन पैकेट भेजकर .

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

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

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

नोट

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

अंत में, चार्ट प्रेमियों के लिए कुछ चार्ट।

प्रत्येक सर्वर के लिए आने वाले मेट्रिक्स की संख्या पर आंकड़े: 2 मिलियन से अधिक एमपीएस।

किसी एक नोड को अक्षम करना और आने वाली मेट्रिक्स को पुनर्वितरित करना।

आउटगोइंग मेट्रिक्स पर आँकड़े: केवल एक नोड हमेशा भेजता है - रेड बॉस।

विभिन्न सिस्टम मॉड्यूल में त्रुटियों को ध्यान में रखते हुए, प्रत्येक नोड के संचालन के आँकड़े।

आने वाली मेट्रिक्स का विवरण (मीट्रिक नाम छिपे हुए हैं)।

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

बेशक, परियोजना के विकास में मदद करने के लिए हर किसी का स्वागत है: पीआर, मुद्दे बनाएं, यदि संभव हो तो हम जवाब देंगे, सुधार करेंगे, आदि।

जैसा कि कहा गया है, बस इतना ही, दोस्तों, हमारे हाथी खरीद लो!

स्रोत: www.habr.com