Bioyino - वितरित, स्केलेबल मेट्रिक्स एग्रीगेटर

त्यसैले तपाईं मेट्रिक्स सङ्कलन। हामी जस्तै। हामी मेट्रिकहरू पनि सङ्कलन गर्छौं। निस्सन्देह, व्यापार को लागी आवश्यक छ। आज हामी हाम्रो निगरानी प्रणालीको पहिलो लिङ्कको बारेमा कुरा गर्नेछौं - एक statsd-compatible aggregation सर्भर bioyino, हामीले यो किन लेख्यौं र हामीले ब्रुबेक किन त्याग्यौं।

हाम्रा अघिल्ला लेखहरूबाट (1, 2) तपाईले पत्ता लगाउन सक्नुहुन्छ कि केहि समय सम्म हामीले प्रयोग गरेर अंकहरू संकलन गर्यौं ब्रुबेक। यो C मा लेखिएको छ। कोडको दृष्टिकोणबाट, यो प्लग जत्तिकै सरल छ (तपाईले योगदान गर्न चाहनुहुँदा यो महत्त्वपूर्ण छ) र सबैभन्दा महत्त्वपूर्ण कुरा, यसले हाम्रो 2 मिलियन मेट्रिक्स प्रति सेकेन्ड (MPS) को चरम मात्रामा ह्यान्डल गर्छ। कुनै पनि समस्या बिना। कागजातले तारा चिन्हको साथ 4 मिलियन MPS लाई समर्थन गर्दछ। यसको मतलब यो हो कि यदि तपाईले लिनक्समा सञ्जाललाई ठीकसँग कन्फिगर गर्नुभयो भने तपाईले उल्लेखित आंकडा पाउनुहुनेछ। (हामीलाई थाहा छैन यदि तपाईले नेटवर्क छोड्नुभयो भने तपाईले कति MPS प्राप्त गर्न सक्नुहुन्छ)। यी फाइदाहरूको बावजुद, हामीसँग ब्रुबेकको बारेमा धेरै गम्भीर गुनासोहरू थिए।

दावी १. Github, परियोजनाको विकासकर्ता, यसलाई समर्थन गर्न बन्द गर्यो: प्याच र फिक्सहरू प्रकाशन गर्दै, हाम्रो र (हाम्रो मात्र होइन) PR स्वीकार गर्दै। पछिल्ला केही महिनाहरूमा (कतै फेब्रुअरी-मार्च 2018 बाट), गतिविधि पुन: सुरु भएको छ, तर त्यो भन्दा पहिले लगभग 2 वर्ष पूर्ण शान्त थियो। साथै, परियोजना विकास भइरहेको छ आन्तरिक Gihub आवश्यकताहरूको लागि, जुन नयाँ सुविधाहरूको परिचयमा गम्भीर बाधा हुन सक्छ।

दावी १. गणनाको शुद्धता। Brubeck जम्मा गर्न को लागी कुल 65536 मानहरू सङ्कलन गर्दछ। हाम्रो अवस्थामा, केही मेट्रिक्सका लागि, एकत्रीकरण अवधि (30 सेकेन्ड) को समयमा, धेरै अधिक मानहरू आउन सक्छ (1 शिखरमा)। यस नमूनाको परिणामको रूपमा, अधिकतम र न्यूनतम मानहरू बेकार देखिन्छन्। उदाहरण को लागी, यो जस्तै:

जस्तै थियो

कस्तो हुनुपथ्र्यो

एउटै कारणको लागि, रकमहरू सामान्यतया गलत रूपमा गणना गरिन्छ। यहाँ 32-बिट फ्लोट ओभरफ्लो भएको बग थप्नुहोस्, जसले सामान्यतया निर्दोष मेट्रिक प्राप्त गर्दा सर्भरलाई सेगफल्टमा पठाउँछ, र सबै कुरा उत्कृष्ट हुन्छ। बग, वैसे, फिक्स गरिएको छैन।

र अन्तमा दावी एक्स। लेख्ने समयमा, हामी यसलाई फेला पार्न सक्षम भएका सबै 14 बढी वा कम काम गर्ने statsd कार्यान्वयनहरूमा प्रस्तुत गर्न तयार छौं। कल्पना गरौं कि कुनै एकल पूर्वाधार यति धेरै बढेको छ कि ४ मिलियन MPS स्वीकार गर्न अब पर्याप्त छैन। वा यो अझै बढेको छैन भने पनि, तर मेट्रिकहरू पहिले नै तपाईंको लागि यति महत्त्वपूर्ण छन् कि चार्टहरूमा छोटो, 4-2 मिनेटको डुब्न पनि पहिले नै महत्वपूर्ण बन्न सक्छ र व्यवस्थापकहरू बीच दुर्गम अवसादको बाउट्स हुन सक्छ। डिप्रेसनको उपचार गर्नु एक अकृतज्ञ कार्य भएकोले प्राविधिक समाधानहरू आवश्यक छ।

सर्वप्रथम, गल्ती सहिष्णुता, ताकि सर्भरमा अचानक समस्याले अफिसमा मनोवैज्ञानिक जोम्बी एपोकेलिप्सको कारण बनाउँदैन। दोस्रो, लिनक्स नेटवर्क स्ट्याकमा गहिरो खन्ने र शान्त रूपमा आवश्यक आकारमा "चौडाइमा" बढ्दै बिना, 4 मिलियन भन्दा बढी MPS स्वीकार गर्न सक्षम हुन स्केलिङ।

हामीसँग स्केलिंगको लागि ठाउँ भएकोले, हामीले गल्ती सहिष्णुताको साथ सुरु गर्ने निर्णय गर्यौं। "बारेमा! दोष सहिष्णुता! यो सरल छ, हामी यो गर्न सक्छौं," हामीले सोच्यौं र 2 सर्भरहरू सुरू गर्यौं, प्रत्येकमा brubeck को प्रतिलिपि उठाउँदै। यो गर्नको लागि, हामीले दुबै सर्भरहरूमा मेट्रिक्सको साथ ट्राफिक प्रतिलिपि गर्नुपर्‍यो र यसका लागि लेख्नुपर्‍यो सानो उपयोगिता। हामीले यससँग गल्ती सहिष्णुता समस्या समाधान गर्यौं, तर ... धेरै राम्रो छैन। सुरुमा सबै कुरा राम्रो देखिन्थ्यो: प्रत्येक ब्रुबेकले आफ्नो सङ्ग्रहको आफ्नै संस्करण सङ्कलन गर्छ, प्रत्येक ३० सेकेन्डमा ग्रेफाइटमा डाटा लेख्छ, पुरानो अन्तराललाई ओभरराइट गर्दै (यो ग्रेफाइट साइडमा गरिन्छ)। यदि एउटा सर्भर अचानक असफल भयो भने, हामीसँग जहिले पनि दोस्रो सर्भर हुन्छ जसको समग्र डाटाको आफ्नै प्रतिलिपि हुन्छ। तर यहाँ समस्या छ: यदि सर्भर असफल भयो भने, ग्राफहरूमा "स" देखा पर्दछ। यो तथ्यको कारण हो कि ब्रुबेकको 30-सेकेन्ड अन्तरालहरू सिङ्क्रोनाइज गरिएको छैन, र क्र्यासको क्षणमा तिनीहरू मध्ये एक ओभरराइट गरिएको छैन। जब दोस्रो सर्भर सुरु हुन्छ, त्यही कुरा हुन्छ। धेरै सहन योग्य, तर म अझ राम्रो चाहन्छु! स्केलेबिलिटीको समस्या पनि हटेको छैन। सबै मेट्रिकहरू अझै पनि एकल सर्भरमा "उडान" छन्, र त्यसैले हामी नेटवर्क स्तरको आधारमा उही 30-2 मिलियन MPS मा सीमित छौं।

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

र त्यसपछि हामीले "खेलौना" statsd - bioyino को बारेमा सम्झ्यौं, जुन Just for Fun hackathon मा लेखिएको थियो (परियोजनाको नाम ह्याकाथन सुरु हुनु अघि स्क्रिप्ट द्वारा उत्पन्न गरिएको थियो) र हामीलाई तुरुन्तै हाम्रो आफ्नै statsd आवश्यक छ भन्ने महसुस भयो। के को लागि?

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

केमा लेख्ने ? अवश्य पनि, Rust मा। किन?

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

त्यहाँ रस्ट विरुद्ध तर्क पनि थियो। कम्पनीसँग रस्टमा परियोजनाहरू सिर्जना गर्ने कुनै अनुभव थिएन, र अब हामी यसलाई मुख्य परियोजनामा ​​प्रयोग गर्ने योजना पनि गर्दैनौं। त्यसकारण, त्यहाँ गम्भीर डर थियो कि केहि काम गर्दैन, तर हामीले मौका लिने निर्णय गर्यौं र प्रयास गर्यौं।

समय बित्यो...

अन्तमा, धेरै असफल प्रयास पछि, पहिलो काम संस्करण तयार थियो। के भयो? यस्तो भयो ।

प्रत्येक नोडले मेट्रिक्सको आफ्नै सेट प्राप्त गर्छ र तिनीहरूलाई जम्मा गर्छ, र ती प्रकारहरूको लागि मेट्रिकहरू जम्मा गर्दैन जहाँ तिनीहरूको पूर्ण सेट अन्तिम एकत्रीकरणको लागि आवश्यक हुन्छ। नोडहरू एक-अर्कासँग कुनै प्रकारको वितरित लक प्रोटोकलद्वारा जोडिएका छन्, जसले तपाईंलाई तिनीहरूमध्ये एक मात्र (यहाँ हामीले रोयौं) चयन गर्न अनुमति दिन्छ जुन महान एकलाई मेट्रिक्स पठाउन योग्य छ। अहिले यो समस्याको समाधान भइरहेको छ कन्सुलर, तर भविष्यमा लेखकको महत्वाकांक्षा विस्तार हुन्छ आफ्नै कार्यान्वयन राफ्ट, जहाँ सबैभन्दा योग्य एक, अवश्य पनि, सहमति नेता नोड हुनेछ। सहमतिको अतिरिक्त, नोडहरू प्रायः (पूर्वनिर्धारित रूपमा प्रति सेकेन्डमा एक पटक) तिनीहरूका छिमेकीहरूलाई पूर्व-एकत्रित मेट्रिक्सका ती भागहरू पठाउँछन् जुन तिनीहरूले सेकेन्डमा सङ्कलन गर्न व्यवस्थित गरे। यो बाहिर जान्छ कि स्केलिंग र त्रुटि सहिष्णुता संरक्षित छ - प्रत्येक नोड अझै पनि मेट्रिक्स को एक पूर्ण सेट होल्ड गर्दछ, तर मेट्रिक्स पहिले नै एकत्रित पठाइन्छ, TCP मार्फत र बाइनरी प्रोटोकल मा इन्कोड गरिएको छ, त्यसैले नक्कल लागत UDP को तुलनामा उल्लेखनीय रूपमा कम हुन्छ। आगमन मेट्रिक्स को पर्याप्त संख्या को बावजुद, संचय धेरै कम मेमोरी र कम CPU को आवश्यकता छ। हाम्रो उच्च संकुचन योग्य mertics को लागी, यो डाटा को केहि दस मेगाबाइट मात्र हो। अतिरिक्त बोनसको रूपमा, हामीले ग्रेफाइटमा कुनै अनावश्यक डेटा पुन: लेख्ने छैनौं, जस्तै बर्बेकको मामलामा थियो।

मेट्रिक्सको साथ UDP प्याकेटहरू एक साधारण राउन्ड रोबिन मार्फत नेटवर्क उपकरणहरूमा नोडहरू बीच असन्तुलित छन्। निस्सन्देह, नेटवर्क हार्डवेयरले प्याकेटहरूको सामग्रीहरू पार्स गर्दैन र त्यसैले प्रति सेकेन्ड 4M प्याकेटहरू भन्दा धेरै तान्न सक्छ, मेट्रिकहरू उल्लेख नगर्नुहोस् जसको बारेमा यो केहि पनि थाहा छैन। यदि हामीले प्रत्येक प्याकेटमा मेट्रिक्स एक पटकमा आउँदैन भन्ने कुरालाई ध्यानमा राख्यौं भने, हामी यस ठाउँमा कुनै पनि कार्यसम्पादन समस्याहरूको पूर्वानुमान गर्दैनौं। यदि सर्भर क्र्यास भयो भने, सञ्जाल उपकरणले चाँडै (१-२ सेकेन्ड भित्र) यो तथ्य पत्ता लगाउँछ र क्र्यास भएको सर्भरलाई रोटेशनबाट हटाउँछ। यसको नतिजाको रूपमा, निष्क्रिय (अर्थात, गैर-नेता) नोडहरू चार्टहरूमा ड्रडाउनहरू ध्यान नदिई व्यावहारिक रूपमा सक्रिय र बन्द गर्न सकिन्छ। हामीले गुमाउने अधिकतम मेट्रिक्सको अंश हो जुन अन्तिम सेकेन्डमा आयो। नेताको अचानक हानि/सटडाउन/स्विचले अझै पनि सानो विसंगति सिर्जना गर्नेछ (३० सेकेन्ड अन्तराल अझै सिङ्कबाट बाहिर छ), तर यदि नोडहरू बीच सञ्चार छ भने, यी समस्याहरूलाई कम गर्न सकिन्छ, उदाहरणका लागि, सिङ्क्रोनाइजेसन प्याकेटहरू पठाएर। ।

आन्तरिक संरचनाको बारेमा थोरै। एप्लिकेसन पक्कै पनि मल्टिथ्रेडेड छ, तर थ्रेडिङ आर्किटेक्चर ब्रुबेकमा प्रयोग गरिएको भन्दा फरक छ। Brubeck मा थ्रेडहरू समान छन् - तिनीहरूमध्ये प्रत्येक जानकारी सङ्कलन र एकत्रीकरणको लागि जिम्मेवार छ। बायोइनोमा, कामदारहरूलाई दुई समूहमा विभाजन गरिएको छ: सञ्जालका लागि जिम्मेवार र एकीकरणका लागि जिम्मेवारहरू। यो विभाजनले मेट्रिक्सको प्रकारको आधारमा अनुप्रयोगलाई थप लचिलो रूपमा व्यवस्थापन गर्न अनुमति दिन्छ: जहाँ गहन एकत्रीकरण आवश्यक छ, तपाइँ एग्रीगेटरहरू थप्न सक्नुहुन्छ, जहाँ नेटवर्क ट्राफिक धेरै छ, तपाइँ नेटवर्क प्रवाहहरूको संख्या थप्न सक्नुहुन्छ। हाल, हाम्रो सर्भरहरूमा हामी 8 नेटवर्क र 4 एकत्रीकरण प्रवाहमा काम गर्छौं।

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

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

भन्नु

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

अन्तमा, चार्ट प्रेमीहरूको लागि केही चार्टहरू।

प्रत्येक सर्भरको लागि आगमन मेट्रिक्सको संख्यामा तथ्याङ्कहरू: 2 मिलियन भन्दा बढी MPS।

नोडहरू मध्ये एक असक्षम गर्दै र आगमन मेट्रिक्स पुन: वितरण।

बाहिर जाने मेट्रिक्स मा तथ्याङ्क: केवल एक नोड सधैं पठाउँछ - छापा मालिक।

प्रत्येक नोडको सञ्चालनको तथ्याङ्क, विभिन्न प्रणाली मोड्युलहरूमा खाता त्रुटिहरू लिँदै।

आगमन मेट्रिक्सको विवरण (मेट्रिक नामहरू लुकेका छन्)।

हामी यो सबै संग अब के गर्ने योजना छ? अवश्य, कोड लेख्नुहोस्, धिक्कार! यो परियोजना सुरुमा खुला स्रोत हुने योजना थियो र जीवनभर यस्तै रहनेछ। हाम्रा तत्काल योजनाहरूमा राफ्टको आफ्नै संस्करणमा स्विच गर्ने, पियर प्रोटोकललाई थप पोर्टेबलमा परिवर्तन गर्ने, थप आन्तरिक तथ्याङ्कहरू, नयाँ प्रकारका मेट्रिकहरू, बग समाधानहरू र अन्य सुधारहरू समावेश गर्ने समावेश छ।

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

यसो भनिरहँदा, सबै मानिसहरू, हाम्रा हात्तीहरू किन्नुहोस्!

स्रोत: www.habr.com