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

त्यामुळे तुम्ही मेट्रिक्स गोळा करा. जसे आपण आहोत. आम्ही मेट्रिक्स देखील गोळा करतो. अर्थात, व्यवसायासाठी आवश्यक. आज आम्ही आमच्या मॉनिटरिंग सिस्टमच्या पहिल्या लिंकबद्दल बोलू - एक statsd-सुसंगत एकत्रीकरण सर्व्हर बायोयिनो, आम्ही ते का लिहिले आणि आम्ही ब्रुबेक का सोडले.

आमच्या मागील लेखांमधून (1, 2) आपण शोधू शकता की काही काळापर्यंत आम्ही वापरून गुण गोळा केले ब्रुबेक. हे C मध्ये लिहिलेले आहे. कोडच्या दृष्टिकोनातून, हे प्लगसारखे सोपे आहे (जेव्हा तुम्ही योगदान देऊ इच्छिता तेव्हा हे महत्त्वाचे आहे) आणि सर्वात महत्त्वाचे म्हणजे, ते आमचे 2 दशलक्ष मेट्रिक्स प्रति सेकंद (एमपीएस) शिखरावर हाताळते. कोणत्याही समस्यांशिवाय. दस्तऐवजीकरण तारांकनासह 4 दशलक्ष MPS साठी समर्थन दर्शवते. याचा अर्थ तुम्ही Linux वर नेटवर्क योग्यरितीने कॉन्फिगर केल्यास तुम्हाला नमूद केलेली आकृती मिळेल. (तुम्ही नेटवर्क जसे आहे तसे सोडल्यास तुम्हाला किती MPS मिळतील हे आम्हाला माहीत नाही). हे फायदे असूनही, आमच्याकडे ब्रुबेकबद्दल अनेक गंभीर तक्रारी होत्या.

दावा १. Github, प्रकल्पाच्या विकसकाने, त्याचे समर्थन करणे थांबवले: पॅच आणि निराकरणे प्रकाशित करणे, आमचे आणि (केवळ आमचेच नाही) PR स्वीकारणे. गेल्या काही महिन्यांत (कोठेतरी फेब्रुवारी-मार्च 2018 पासून), क्रियाकलाप पुन्हा सुरू झाला आहे, परंतु त्यापूर्वी जवळजवळ 2 वर्षे पूर्ण शांतता होती. याव्यतिरिक्त, प्रकल्प विकसित केला जात आहे अंतर्गत गिहुब गरजांसाठी, जे नवीन वैशिष्ट्यांच्या परिचयात एक गंभीर अडथळा बनू शकते.

दावा १. गणनेची अचूकता. Brubeck एकत्रीकरणासाठी एकूण 65536 मूल्ये गोळा करतो. आमच्या बाबतीत, काही मेट्रिक्ससाठी, एकत्रीकरण कालावधीत (३० सेकंद), बरीच मूल्ये येऊ शकतात (१,५२७,३९२ शिखरावर). या सॅम्पलिंगच्या परिणामी, कमाल आणि किमान मूल्ये निरुपयोगी दिसतात. उदाहरणार्थ, यासारखे:

जसे होते तसे

ते कसे असावे

त्याच कारणास्तव, रक्कम सामान्यतः चुकीच्या पद्धतीने मोजली जाते. येथे 32-बिट फ्लोट ओव्हरफ्लोसह एक बग जोडा, जे सर्वसाधारणपणे निष्पाप मेट्रिक प्राप्त करताना सर्व्हरला सेगफॉल्टवर पाठवते आणि सर्वकाही छान होते. बग, तसे, निराकरण केले गेले नाही.

आणि, शेवटी, दावा X. लेखनाच्या वेळी, आम्ही शोधण्यात सक्षम असलेल्या सर्व 14 अधिक किंवा कमी कार्यरत statsd अंमलबजावणीसाठी सादर करण्यास तयार आहोत. चला कल्पना करूया की काही एकल पायाभूत सुविधा इतक्या वाढल्या आहेत की 4 दशलक्ष एमपीएस स्वीकारणे आता पुरेसे नाही. किंवा ते अद्याप वाढले नसले तरीही, परंतु मेट्रिक्स तुमच्यासाठी आधीच इतके महत्त्वाचे आहेत की अगदी लहान, 2-3 मिनिटांच्या तक्त्यांमध्ये कमी होणे आधीच गंभीर बनू शकते आणि व्यवस्थापकांमध्ये दुर्दम्य नैराश्य निर्माण करू शकते. नैराश्यावर उपचार करणे हे एक कृतघ्न कार्य असल्याने, तांत्रिक उपाय आवश्यक आहेत.

प्रथम, दोष सहिष्णुता, जेणेकरून सर्व्हरवरील अचानक समस्या ऑफिसमध्ये मनोरुग्ण झोम्बी सर्वनाश होऊ नये. दुसरे म्हणजे, लिनक्स नेटवर्क स्टॅकमध्ये खोलवर न जाता आणि आवश्यक आकारात शांतपणे “रुंदीमध्ये” वाढल्याशिवाय 4 दशलक्ष एमपीएस स्वीकारण्यास सक्षम होण्यासाठी स्केलिंग.

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

जर आपण समस्येबद्दल थोडासा विचार केला आणि त्याच वेळी फावडे वापरून बर्फ खोदला तर खालील स्पष्ट कल्पना मनात येऊ शकते: आपल्याला एक statsd आवश्यक आहे जो वितरित मोडमध्ये कार्य करू शकेल. म्हणजे, वेळ आणि मेट्रिक्समधील नोड्स दरम्यान सिंक्रोनाइझेशन लागू करणारे. “अर्थात, असा उपाय कदाचित आधीच अस्तित्वात आहे,” आम्ही म्हणालो आणि Google वर गेलो…. आणि त्यांना काहीही सापडले नाही. वेगवेगळ्या स्टॅट्सडीसाठी कागदपत्रे तपासल्यानंतर (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 डिसेंबर XNUMX पर्यंत), आम्हाला काहीही सापडले नाही. वरवर पाहता, विकसक किंवा या सोल्यूशन्सच्या वापरकर्त्यांनी अद्याप बर्याच मेट्रिक्सचा सामना केला नाही, अन्यथा ते निश्चितपणे काहीतरी घेऊन येतील.

आणि मग आम्हाला "टॉय" स्टॅट्सडी - बायोयिनो बद्दल आठवले, जे जस्ट फॉर फन हॅकाथॉनमध्ये लिहिले गेले होते (हॅकॅथॉन सुरू होण्यापूर्वी या प्रकल्पाचे नाव स्क्रिप्टद्वारे तयार केले गेले होते) आणि लक्षात आले की आम्हाला आमच्या स्वतःच्या स्टॅट्सडीची तातडीने गरज आहे. कशासाठी?

• कारण जगात स्टॅट्सडी क्लोन खूप कमी आहेत,
• कारण इच्छित दोष सहिष्णुता आणि स्केलेबिलिटी (सर्व्हर दरम्यान एकत्रित मेट्रिक्स सिंक्रोनाइझ करणे आणि विवाद पाठविण्याच्या समस्येचे निराकरण करण्यासह) इच्छित किंवा त्याच्या जवळ प्रदान करणे शक्य आहे.
• कारण ब्रुबेकपेक्षा मेट्रिक्सची अधिक अचूक गणना करणे शक्य आहे,
• कारण तुम्ही स्वतः अधिक तपशीलवार आकडेवारी गोळा करू शकता, जी ब्रुबेकने आम्हाला व्यावहारिकरित्या प्रदान केली नाही,
• कारण मला माझ्या स्वतःच्या हायपरपरफॉर्मन्स डिस्ट्रिब्युटेड स्केल लॅब ऍप्लिकेशनला प्रोग्राम करण्याची संधी मिळाली होती, जे दुसर्‍या समान हायपरफॉरच्या आर्किटेक्चरची पूर्णपणे पुनरावृत्ती करणार नाही... ठीक आहे.

कशावर लिहायचे? अर्थात, गंज मध्ये. का?

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

रस्ट विरुद्ध एक युक्तिवाद देखील होता. कंपनीला रस्टमध्ये प्रकल्प तयार करण्याचा कोणताही अनुभव नव्हता आणि आता आम्ही ते मुख्य प्रकल्पात वापरण्याची योजना करत नाही. त्यामुळे काहीही निष्पन्न होणार नाही अशी गंभीर भीती होती, पण आम्ही संधी साधण्याचा निर्णय घेतला आणि प्रयत्न केला.

वेळ निघून गेली...

शेवटी, अनेक अयशस्वी प्रयत्नांनंतर, प्रथम कार्यरत आवृत्ती तयार झाली. काय झालं? हा प्रकार घडला.

प्रत्येक नोडला मेट्रिक्सचा स्वतःचा संच प्राप्त होतो आणि तो जमा करतो आणि त्या प्रकारांसाठी मेट्रिक्स एकत्रित करत नाही जेथे अंतिम एकत्रीकरणासाठी त्यांचा संपूर्ण संच आवश्यक असतो. नोड्स काही प्रकारच्या वितरित लॉक प्रोटोकॉलद्वारे एकमेकांशी जोडलेले आहेत, जे तुम्हाला त्यांच्यापैकी एकमेव (येथे आम्ही ओरडलो) निवडण्याची परवानगी देतो जो महान व्यक्तीला मेट्रिक्स पाठविण्यास पात्र आहे. द्वारे सध्या ही समस्या सोडवली जात आहे वाणिज्य, परंतु भविष्यात लेखकाच्या महत्त्वाकांक्षा वाढतात स्वतःचे अंमलबजावणी राफ्ट, जिथे सर्वात योग्य व्यक्ती, अर्थातच, एकमत लीडर नोड असेल. सहमती व्यतिरिक्त, नोड्स बर्‍याचदा (डिफॉल्टनुसार प्रति सेकंदात एकदा) त्यांच्या शेजाऱ्यांना पूर्व-एकत्रित मेट्रिक्सचे ते भाग पाठवतात जे त्यांनी त्या सेकंदात गोळा करण्यात व्यवस्थापित केले. असे दिसून आले की स्केलिंग आणि दोष सहिष्णुता जतन केली गेली आहे - प्रत्येक नोडमध्ये अद्याप मेट्रिक्सचा संपूर्ण संच आहे, परंतु मेट्रिक्स आधीपासूनच एकत्रितपणे, TCP द्वारे पाठवले जातात आणि बायनरी प्रोटोकॉलमध्ये एन्कोड केले जातात, त्यामुळे UDP च्या तुलनेत डुप्लिकेशन खर्च लक्षणीयरीत्या कमी केला जातो. मोठ्या प्रमाणात इनकमिंग मेट्रिक्स असूनही, जमा होण्यासाठी खूप कमी मेमरी आणि अगदी कमी CPU आवश्यक आहे. आमच्या अत्यंत संकुचित करण्यायोग्य गुणांसाठी, हा फक्त काही दहा मेगाबाइट डेटा आहे. अतिरिक्त बोनस म्हणून, आम्हाला ग्रेफाइटमध्ये कोणतेही अनावश्यक डेटा पुनर्लेखन मिळत नाही, जसे बर्बेकच्या बाबतीत होते.

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

अंतर्गत रचना बद्दल थोडे. अनुप्रयोग, अर्थातच, मल्टीथ्रेडेड आहे, परंतु थ्रेडिंग आर्किटेक्चर ब्रुबेकमध्ये वापरल्या जाणार्‍यापेक्षा वेगळे आहे. ब्रुबेकमधील धागे समान आहेत - त्यातील प्रत्येक माहिती संकलन आणि एकत्रीकरणासाठी जबाबदार आहे. बायोयिनोमध्ये, कामगारांना दोन गटांमध्ये विभागले गेले आहे: जे नेटवर्कसाठी जबाबदार आहेत आणि जे एकत्रीकरणासाठी जबाबदार आहेत. हा विभाग तुम्हाला मेट्रिक्सच्या प्रकारावर अवलंबून अनुप्रयोग अधिक लवचिकपणे व्यवस्थापित करण्यास अनुमती देतो: जेथे गहन एकत्रीकरण आवश्यक आहे, तेथे तुम्ही एग्रीगेटर जोडू शकता, जेथे भरपूर नेटवर्क रहदारी आहे, तुम्ही नेटवर्क प्रवाहांची संख्या जोडू शकता. याक्षणी, आमच्या सर्व्हरवर आम्ही 8 नेटवर्क आणि 4 एकत्रीकरण प्रवाहांमध्ये कार्य करतो.

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

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

शेरा

डीफॉल्ट सेटिंग्जमध्ये, बफरचा आकार बराच मोठा असेल. जर तुम्ही अचानक सर्व्हर वापरून पाहण्याचा निर्णय घेतला, तर तुम्हाला ही वस्तुस्थिती येऊ शकते की थोड्या प्रमाणात मेट्रिक्स पाठवल्यानंतर ते ग्रेफाइटमध्ये येणार नाहीत, नेटवर्क स्ट्रीम बफरमध्ये राहतील. कमी संख्येच्या मेट्रिक्ससह कार्य करण्यासाठी, तुम्हाला कॉन्फिगरेशनमधील लहान मूल्यांवर बफसाईझ आणि टास्क-क्यू-आकार सेट करणे आवश्यक आहे.

शेवटी, चार्ट प्रेमींसाठी काही चार्ट.

प्रत्येक सर्व्हरसाठी येणार्‍या मेट्रिक्सच्या संख्येवरील आकडेवारी: 2 दशलक्ष एमपीएसपेक्षा जास्त.

एक नोड अक्षम करणे आणि येणारे मेट्रिक्सचे पुनर्वितरण करणे.

आउटगोइंग मेट्रिक्सवरील आकडेवारी: फक्त एक नोड नेहमी पाठवतो - छापा बॉस.

विविध सिस्टम मॉड्यूल्समधील त्रुटी लक्षात घेऊन प्रत्येक नोडच्या ऑपरेशनची आकडेवारी.

येणार्‍या मेट्रिक्सचे तपशील (मेट्रिक नावे लपविली आहेत).

या सगळ्याचे पुढे काय करायचे ठरवले आहे? अर्थात, कोड लिहा, अरेरे...! हा प्रकल्प मूळतः मुक्त-स्रोत असण्याची योजना होती आणि आयुष्यभर तसाच राहील. आमच्या तात्काळ योजनांमध्ये राफ्टच्या आमच्या स्वतःच्या आवृत्तीवर स्विच करणे, पीअर प्रोटोकॉल अधिक पोर्टेबलमध्ये बदलणे, अतिरिक्त अंतर्गत आकडेवारी सादर करणे, नवीन प्रकारचे मेट्रिक्स, दोष निराकरणे आणि इतर सुधारणा समाविष्ट आहेत.

अर्थात, प्रकल्पाच्या विकासात मदत करण्यासाठी प्रत्येकाचे स्वागत आहे: PR, समस्या तयार करा, शक्य असल्यास आम्ही प्रतिसाद देऊ, सुधारू इ.

म्हटल्याबरोबर, लोकांनो, आमचे हत्ती विकत घ्या!

स्त्रोत: www.habr.com