माइक्रोसेर्विसेज के लिए वितरित लॉगिंग और ट्रेसिंग

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

यदि लॉगिंग अच्छी तरह से व्यवस्थित है, तो यह आपको यह समझने की अनुमति देता है कि क्या, कब और कैसे गलत हो जाता है, और उन लोगों को आवश्यक जानकारी देने के लिए जिन्हें इन त्रुटियों को ठीक करना है। एक ऐसी प्रणाली के लिए जिसमें १० देशों के १० डेटा सेंटरों में हर सेकंड १०० हजार संदेश भेजे जाते हैं, और ३५० इंजीनियर हर दिन कुछ न कुछ तैनात करते हैं, लॉगिंग सिस्टम विशेष रूप से महत्वपूर्ण है।



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

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


आपको संदर्भ से परिचित कराने के लिए, मैं आपको कंपनी के बारे में थोड़ा बताऊंगा। हम ग्राहकों-संगठनों को अपने ग्राहकों को संदेश देने में मदद करते हैं: एक टैक्सी सेवा से संदेश, रद्द करने के बारे में बैंक से एसएमएस, या वीसी में प्रवेश करते समय एक बार का पासवर्ड। 190 देशों के ग्राहकों के लिए हर दिन 350 मिलियन संदेश हमारे पास से गुजरते हैं। उनमें से प्रत्येक हम स्वीकार करते हैं, प्रक्रिया, बिल, मार्ग, अनुकूलन, ऑपरेटरों को भेजते हैं, और विपरीत दिशा में, वितरण रिपोर्ट की प्रक्रिया करते हैं और विश्लेषिकी उत्पन्न करते हैं।

इस तरह के संस्करणों में काम करने के लिए हमारे पास यह है:

• दुनिया भर में 36 डेटा सेंटर;
  
• 5000+ वर्चुअल मशीनें
  
• 350+ इंजीनियर;
  
• 730+ विभिन्न माइक्रोसर्विसेज।
  

यह एक जटिल प्रणाली है, और एक भी गुरु पूर्ण पैमाने पर एकल-हाथ नहीं समझ सकता है। हमारी कंपनी के मुख्य लक्ष्यों में से एक नई सुविधाओं के वितरण की उच्च गति और व्यापार के लिए रिलीज़ है। इस मामले में, सब कुछ काम करना चाहिए और गिरना नहीं चाहिए। हम इस पर काम कर रहे हैं: 2017 में 40,000 तैनाती, 2018 में 80,000, प्रति दिन 300 तैनाती।

हमारे पास 350 इंजीनियर हैं - यह पता चला है कि हर इंजीनियर रोजाना कुछ न कुछ करता है । कुछ साल पहले, एक कंपनी में केवल एक व्यक्ति के पास ऐसी उत्पादकता थी - कृशिमीर, जो हमारे प्रमुख इंजीनियर थे। लेकिन हमने यह सुनिश्चित किया कि जब वह डिप्लॉय बटन दबाता है या स्क्रिप्ट चलाता है, तो हर इंजीनियर क्रेसीमीर के रूप में आत्मविश्वास महसूस करता है।

इसके लिए क्या आवश्यक है? सबसे पहले, आत्मविश्वास कि हम समझते हैं कि सिस्टम में क्या हो रहा है और यह किस अवस्था में है। आत्मविश्वास प्रणाली को एक प्रश्न पूछने और घटना के दौरान और कोड के विकास के दौरान समस्या के कारण का पता लगाने की क्षमता द्वारा दिया जाता है।

इस आत्मविश्वास को प्राप्त करने के लिए, हम अवलोकन में निवेश करते हैं। परंपरागत रूप से, यह शब्द तीन घटकों को जोड़ता है:

• प्रवेश;
  
• मैट्रिक्स;
  
• ट्रेसिंग।
  

हम इस बारे में बात करेंगे सबसे पहले, आइए लॉगिंग के लिए हमारे समाधान को देखें, लेकिन हम मैट्रिक्स और निशान पर भी स्पर्श करेंगे।

विकास

हमारे सहित लॉगिंग का लगभग कोई भी अनुप्रयोग या प्रणाली, विकास के कई चरणों से गुजरती है।

पहला चरण कंसोल के आउटपुट के लिए है ।

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

जैसे ही हमारी सेवा या विभिन्न सेवाओं के कई उदाहरण हैं, डेवलपर्स और समर्थन के लिए लॉग में केंद्रीकृत पहुंच का कार्य दिखाई देता है। हम वितरित लॉगिंग पर आगे बढ़ते हैं - हम विभिन्न सेवाओं को एक ही लॉगिंग सेवा में जोड़ते हैं।

वितरित लॉगिंग

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


ग्रेलॉग में, आप अलर्ट बना सकते हैं, किबाना जैसे चार्ट और यहां तक ​​कि मेट्रिक्स भी लॉग कर सकते हैं।

समस्याओं

हमारी कंपनी बढ़ रही थी, और कुछ समय में यह स्पष्ट हो गया कि ग्रेगल के साथ कुछ गलत था।

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

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

पहला फैसला

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

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

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

आइए लॉग, मैट्रिक्स और निशान लगाने के लिए परिदृश्यों को देखें।

लॉग

उच्च आयामीता, डिबगिंग और अनुसंधान । अच्छे लॉग क्या हैं?

लॉग वे ईवेंट हैं जो हम लॉग करते हैं।

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

मैट्रिक्स

कम आयामीता, एकत्रीकरण, निगरानी और अलर्ट । सभी मीट्रिक संग्रह प्रणालियों के हुड के तहत समय श्रृंखला डेटाबेस हैं। ये डेटाबेस एकत्रीकरण का एक उत्कृष्ट कार्य करते हैं, इसलिए मैट्रिक्स एकत्रीकरण, निगरानी और निर्माण अलर्ट के लिए उपयुक्त हैं।

मेट्रिक्स डेटा आयाम के प्रति बहुत संवेदनशील होते हैं।

मैट्रिक्स के लिए, डेटा का आयाम एक हजार से अधिक नहीं होना चाहिए। यदि हम कुछ अनुरोध आईडी जोड़ते हैं, जिसमें मूल्यों का आकार सीमित नहीं है, तो हम जल्दी से गंभीर समस्याओं का सामना करेंगे। हम पहले ही इस रेक पर कदम रख चुके हैं।

सहसंबंध और निशान

लॉग को सहसंबद्ध किया जाना चाहिए।

संरचित लॉग हमारे लिए डेटा द्वारा आसानी से खोज करने के लिए पर्याप्त नहीं हैं। कुछ निश्चित मान वाले फ़ील्ड होने चाहिए: अनुरोध आईडी, उपयोगकर्ता आईडी, उन सेवाओं का अन्य डेटा जिसमें से लॉग आए थे।

पारंपरिक समाधान प्रणाली के प्रवेश द्वार पर लेनदेन (लॉग) के लिए एक अद्वितीय आईडी असाइन करना है। फिर यह आईडी (संदर्भ) एक सेवा के भीतर या सेवाओं के बीच कॉल की एक श्रृंखला के माध्यम से पूरे सिस्टम के माध्यम से भेजा जाता है।


सहसंबंध और अनुरेखण।

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

पहले हमने जिपकिन का इस्तेमाल किया। पहले से ही 2015 में, हमारे पास इन समाधानों का एक सबूत (पायलट प्रोजेक्ट) था।


वितरित ट्रेस

ऐसी तस्वीर प्राप्त करने के लिए, कोड को इंस्ट्रूमेंट करना होगा । यदि आप पहले से ही मौजूद कोड बेस के साथ काम कर रहे हैं, तो आपको इसके माध्यम से जाने की जरूरत है - इसमें बदलाव की आवश्यकता है।

पूरी तस्वीर पाने के लिए और निशान से लाभ पाने के लिए, आपको श्रृंखला में सभी सेवाओं को साधने की जरूरत है, और न केवल एक सेवा की, जिस पर आप वर्तमान में काम कर रहे हैं।

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

वितरण रिपोर्ट

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

पहले उदाहरण पर विचार करें।


वितरण रिपोर्ट।

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

दो संबंधित लेनदेन एक पूरे लेनदेन के हिस्से हैं। यह जानकारी समर्थन इंजीनियरों और एकीकरण डेवलपर्स के लिए बहुत महत्वपूर्ण है। लेकिन यह एकल ट्रेस या एकल आईडी के आधार पर पूरी तरह से असंभव है।

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



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


हम एक ग्राफ बना रहे हैं।

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

Neo4j

हमने प्रूफ ऑफ कॉन्सेप्ट लागू किया: एक 16-कोर होस्ट जो 100 मिलियन नोड्स और 150 मिलियन लिंक के ग्राफ को प्रोसेस कर सकता था। ग्राफ ने केवल 15 जीबी डिस्क पर कब्जा किया - फिर यह हमारे अनुकूल है।


हमारा निर्णय। लॉग आर्किटेक्चर।

Neo4j के अलावा, अब हमारे पास संबंधित लॉग देखने के लिए एक सरल इंटरफ़ेस है। उसके साथ, इंजीनियर पूरी तस्वीर देखते हैं।

लेकिन बहुत जल्दी, हम इस डेटाबेस में निराश हो गए।

Neo4j के साथ समस्याएं

डेटा रोटेशन । हमारे पास शक्तिशाली वॉल्यूम हैं और डेटा को घुमाया जाना चाहिए। लेकिन जब Neo4j से एक नोड हटा दिया जाता है, तो डिस्क पर डेटा साफ़ नहीं किया जाता है। मुझे एक जटिल समाधान का निर्माण करना था और रेखांकन का पूरी तरह से पुनर्निर्माण करना था।

प्रदर्शन । सभी ग्राफ़ डेटाबेस केवल-पढ़ने के लिए हैं। रिकॉर्डिंग पर, प्रदर्शन काफ़ी कम है। हमारा मामला बिल्कुल विपरीत है: हम बहुत लिखते हैं और अपेक्षाकृत कम ही पढ़े जाते हैं - ये प्रति सेकंड या प्रति मिनट अनुरोधों की इकाइयाँ हैं।

शुल्क के लिए उच्च उपलब्धता और क्लस्टर विश्लेषण । हमारे पैमाने पर, यह सभ्य लागतों में तब्दील हो जाता है।

इसलिए, हम दूसरे रास्ते पर चले गए।

PostgreSQL के साथ समाधान

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

डेटा रोटेशन भी हल करना आसान है। प्रत्येक दिन के लिए हम एक नई प्लेट शुरू करते हैं और कुछ दिनों के बाद जब समय आता है, हम इसे हटा देते हैं और डेटा जारी करते हैं। एक सरल उपाय।

अब हमारे पास PostgreSQL में 850 मिलियन कनेक्शन हैं, वे 100 जीबी डिस्क पर कब्जा कर लेते हैं। हम वहां प्रति सेकंड 30 हजार की गति से लिखते हैं, और डेटाबेस में इसके लिए 2 सीपीयू और 6 जीबी रैम के साथ केवल दो वीएम हैं। आवश्यकतानुसार, PostgreSQL जल्दी से लोंगो को लिख सकता है।

सेवा के लिए अभी भी छोटी मशीनें हैं, जो घूमती हैं और नियंत्रण करती हैं।


हमारी वास्तुकला कैसे बदल गई है।

ग्रेलॉग के साथ चुनौतियां

कंपनी बढ़ी, नए डेटा केंद्र दिखाई दिए, संचार लॉग के साथ एक समाधान के साथ, लोड भी उल्लेखनीय रूप से बढ़ गया। हमें लगा कि ग्रेलॉग अब परफेक्ट नहीं है।

एकीकृत योजना और केंद्रीकरण । मैं 10 डेटा केंद्रों में एक एकल क्लस्टर प्रबंधन उपकरण रखना चाहूंगा। इसके अलावा, एकीकृत डेटा मैपिंग योजना पर भी सवाल उठे ताकि कोई टकराव न हो।

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

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

प्रसंस्करण देरी (कतार) । हमें ग्रेलेग में कतार का मानक कार्यान्वयन पसंद नहीं आया।

MongoDB का समर्थन करने की आवश्यकता । ग्रेनलॉग ने MongoDB को पछाड़ दिया, इस प्रणाली को भी प्रशासित करना आवश्यक था।

हमने महसूस किया कि इस स्तर पर हम अपना समाधान चाहते हैं। शायद डैशबोर्ड के लिए, उपयोग किए जाने वाले अलर्ट के लिए कम शांत विशेषताएं हैं, लेकिन उनका अपना बेहतर है।

हमारा निर्णय

हमने अपनी लॉग सेवा को विकसित किया है।


लॉग सेवा।

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

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

इसलिए, हमने बस फैसला किया - समय पर लिखें।

एक घंटे के लिए एक सूचकांक, अन्य डेटा केंद्रों में एक घंटे के लिए 2 सूचकांक, तीसरे एक सूचकांक में 3 घंटे के लिए, लेकिन सभी समय में। सूचकांक विभिन्न आकारों में प्राप्त किए जाते हैं, क्योंकि रात में यातायात दिन के दौरान कम होता है, लेकिन सामान्य तौर पर यह काम करता है। अनुभव से पता चला है कि किसी भी जटिलता की आवश्यकता नहीं है।

प्रवासन में आसानी के लिए और बड़ी मात्रा में डेटा दिए जाने के लिए, हमने GELF प्रोटोकॉल को चुना, जो एक साधारण टीसीपी-आधारित ग्रेलाग प्रोटोकॉल है। तो हमें नेटली के लिए एक GELF सर्वर और एक GELF डिकोडर मिला।

तब जेन्सन एलाटिक्स खोज के लिए लिखने के लिए एन्कोडेड है। हम Elasticsearch से आधिकारिक जावा एपीआई का उपयोग करते हैं और बल्क में लिखते हैं।

उच्च रिकॉर्डिंग गति के लिए आपको बल्कामी लिखना होगा।

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

थोक प्रोसेसर के साथ समस्या

सब कुछ ठीक लगने लगा है। लेकिन हमने शुरू किया और महसूस किया कि हमने बल्क प्रोसेसर पर आराम किया है - यह अप्रत्याशित था। हम उन मूल्यों को प्राप्त नहीं कर सकते हैं जिनकी हम गिनती कर रहे थे - समस्या कहीं से भी नहीं आई।



मानक कार्यान्वयन में, बल्क प्रोसेसर एकल-थ्रेडेड, सिंक्रोनस है, इस तथ्य के बावजूद कि एक समानता सेटिंग है। यही समस्या थी।

हमने चारों ओर अफरा-तफरी मचाई और यह पता चला कि यह एक ज्ञात, लेकिन सुलझा हुआ बग नहीं है। हमने बल्क प्रोसेसर को थोड़ा बदल दिया - रेन्ट्रेंटलॉक के माध्यम से एक स्पष्ट लॉक बनाया। केवल मई में, इसी तरह के बदलावों को आधिकारिक एलेस्टिक्स खोज भंडार में किया गया था और यह केवल संस्करण 7.3 से उपलब्ध होगा। वर्तमान एक 7.1 है, और हम 6.3 संस्करण का उपयोग कर रहे हैं।

यदि आप एक बल्क-प्रोसेसर के साथ भी काम करते हैं और एलिटिक्स खोज में एक प्रविष्टि को ओवरक्लॉक करना चाहते हैं - गिटहब पर इन परिवर्तनों को देखें और अपने संस्करण में वापस पोर्ट करें। परिवर्तन केवल बल्क प्रोसेसर को प्रभावित करते हैं। यदि आपको नीचे दिए गए संस्करण में पोर्ट करने की आवश्यकता है तो कोई कठिनाई नहीं होगी।

सब कुछ ठीक है, बल्क प्रोसेसर चला गया है, गति तेज हो गई है।



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

इस संबंध में, हमने महसूस किया कि हमें न केवल बफर को स्मृति में लागू करने की आवश्यकता है, बल्कि कतार भी है। हमने फैसला किया कि हम केवल कतार में अस्वीकार किए गए संदेश भेजेंगे - केवल उन लोगों को जो बल्क प्रोसेसर Elasticsearch को नहीं लिख सकते।

वापसी वापसी

यह एक सरल कार्यान्वयन है।

• हम फ़ाइल में अस्वीकृत संदेशों को सहेजते हैं - RejectedExecutionHandler ।
  
• एक अलग निष्पादक में निर्दिष्ट अंतराल पर पुनः सबमिट करें।
  
• हालाँकि, हम नए ट्रैफ़िक में देरी नहीं करते हैं।
  

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


हमारी योजना इस तरह लगने लगी।

अब बात करते हैं कि हम एलीटेसर्च कैसे तैयार करते हैं, हम किन मापदंडों का उपयोग करते हैं और हम कैसे सेट करते हैं।

एलिटिक्स खोज विन्यास

जिस समस्या से हम जूझ रहे हैं, उसकी जरूरत है कि इलास्टिक्स को ओवरक्लॉक किया जाए और इसे लिखने के लिए अनुकूलित किया जाए, क्योंकि पढ़ने की संख्या काफी कम है।

हमने कई मापदंडों का इस्तेमाल किया।

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

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

"index.merge.scheduler.max_thread_count": 1 - एचडीडी के लिए अनुशंसित ।
यदि आपको SSDs नहीं, बल्कि साधारण HDDs मिलते हैं, तो इस पैरामीटर को एक पर सेट करें। इंडेक्स टुकड़ों में लिखे जाते हैं, फिर ये टुकड़े जमे हुए होते हैं। यह डिस्क को थोड़ा बचाता है, लेकिन, सबसे ऊपर, खोज को गति देता है। इसके अलावा, जब आप इंडेक्स पर लिखना बंद कर देते हैं, तो आप force merge कर सकते हैं। जब क्लस्टर पर लोड कम होता है, तो यह स्वचालित रूप से जमा देता है।

"index.unassigned.node_left.delayed_timeout": "5m" - एक नोड के गायब होने पर तैनाती में देरी । यह वह समय है जिसके बाद एलिटिक्स खोज अनुक्रमणिका और डेटा को लागू करना शुरू कर देगा यदि एक नोड को रिबूट किया जाता है, तैनात किया जाता है, या रखरखाव के लिए वापस ले लिया जाता है। लेकिन अगर आपके पास डिस्क और नेटवर्क पर भारी भार है, तो तैनाती एक कठिन ऑपरेशन है। उन्हें अधिभार नहीं देने के लिए, यह समयबाह्य नियंत्रण और समझने में बेहतर है कि देरी की क्या आवश्यकता है।

"index.refresh_interval": -1 - यदि कोई खोज क्वेरी नहीं है, तो अनुक्रमणिका को अपडेट न करें । जब खोज क्वेरी प्रकट होती है तो सूचकांक को अपडेट किया जाएगा। यह इंडेक्स सेकंड और मिनटों में सेट किया जा सकता है।

"index.translogDurability": "async" - कितनी बार fsync निष्पादित करने के लिए: प्रत्येक अनुरोध या समय के साथ। धीमी चाल के लिए प्रदर्शन लाभ देता है।

हमारे पास इसे इस्तेमाल करने का एक दिलचस्प तरीका भी है। समर्थन और डेवलपर्स संदेश के पूरे शरीर में पूर्ण-पाठ खोज और regexp'ov का उपयोग करने में सक्षम होना चाहते हैं। लेकिन इलास्टिसर्च में यह संभव नहीं है - यह केवल उन टोकन द्वारा खोज सकता है जो पहले से ही अपने सिस्टम में मौजूद हैं। RegExp और वाइल्डकार्ड का उपयोग किया जा सकता है, लेकिन टोकन कुछ RegExp से शुरू नहीं हो सकता है। इसलिए, हमने फ़िल्टर में word_delimiter जोड़ा:

 "tokenizer": "standard" "filter" : [ "word_delimiter" ] 

यह स्वचालित रूप से शब्दों को टोकन में विभाजित करता है:

• "वाई-फाई" → "वाई", "फाई";
  
• "पावरशॉट" → "पावर", "शॉट";
  
• "SD500" → "SD", "500"।
  

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

क्लस्टर के बारे में

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

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

उदाहरण के लिए, सेवा के मामले में एक हाइपरविजर के नाम से allocation awareness उपयोग करें । अलग-अलग हाइपरवाइज़रों में अनुक्रमणिका और दाढ़ों को तितर बितर करने में मदद करता है ताकि हाइपरवाइज़र के बाहर निकल जाने पर वे ओवरलैप न हों।

पहले से इंडेक्स बनाएं । अच्छा अभ्यास, खासकर जब समय पर लिखना। सूचकांक तुरंत गर्म है, तैयार है और इसमें कोई देरी नहीं है।

प्रति नोड एक इंडेक्स के श्रोताओं की संख्या को सीमित करें । "index.routing.allocation.total_shards_per_node": 4 प्रति नोड एक सूचकांक के अधिकतम की संख्या है। आदर्श मामले में, उनमें से 2 हैं, हम सिर्फ 4 मामलों में डालते हैं, अगर हमारे पास अभी भी कम कारें हैं।

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

इलास्टिक्सखोज रखरखाव सिफारिशें

जो लोग एलीटेसर्च के साथ काम करते हैं वे इन सिफारिशों से परिचित हैं।

अनुसूचित रखरखाव के दौरान, रोलिंग अपग्रेड के लिए सिफारिशें लागू करें: शार्क आवंटन को अक्षम करें, सिंक किए गए फ़्लश।

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

सिंक किया हुआ फ्लश । इस स्थिति में, नोड क्लस्टर में वापस आने पर बहुत तेज़ी से सिंक्रनाइज़ होता है।

इंडेक्स या रिकवरी पर लिखने पर भारी बोझ के साथ, आप प्रतिकृतियों की संख्या को कम कर सकते हैं।

यदि आप बड़ी मात्रा में डेटा डाउनलोड करते हैं, उदाहरण के लिए, पीक लोड, तो आप शार्ड को बंद कर सकते हैं और बाद में लोड कम होने पर उन्हें बनाने के लिए इलास्टिसर्च को एक कमांड दे सकते हैं।

यहां कुछ आदेश दिए गए हैं जिनका मैं उपयोग करना चाहता हूं:

• GET _cat/thread_pool?v - आपको प्रत्येक नोड पर thread_pool देखने की अनुमति देता है: अब क्या गर्म है, क्या लिखना और पढ़ना कतार हैं।
  
• GET _cat/recovery/?active_only=true - जहां वसूली होती है, वहां अनुक्रमणिका तैनात की जाती हैं।
  
• GET _cluster/allocation/explain - एक सुविधाजनक मानव रूप में क्यों और कौन से अनुक्रमित या प्रतिकृतियां आवंटित नहीं की गईं।
  

निगरानी के लिए हम ग्राफाना का उपयोग करते हैं।



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

लॉगिंग निष्कर्ष

लॉग होना चाहिए:

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

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

उन्होंने ग्राफेटाना के स्रोत के रूप में इलास्टिक्स खोज को जोड़ा और इस डेटा को सहसंबंधित करने, समस्या को बंद करने और काफी तेजी से अच्छे परिणाम प्राप्त करने में सक्षम थे।

अपने स्वयं के समाधानों को उजागर करना बहुत आसान है।

अब, इस समाधान के लिए काम करने वाले 10 ग्रेलॉग समूहों के बजाय, हमारे पास कई सेवाएं हैं। ये 10 डेटा केंद्र हैं, लेकिन हमारे पास एक समर्पित टीम और ऐसे लोग भी नहीं हैं जो उनकी सेवा करते हैं। ऐसे कई लोग हैं जिन्होंने उन पर काम किया और आवश्यकतानुसार कुछ बदला। यह छोटी टीम हमारे बुनियादी ढांचे में पूरी तरह से एकीकृत है - तैनाती और सर्विसिंग आसान और सस्ता है।

मामलों को अलग करें और उचित उपकरणों का उपयोग करें।

ये लॉगिंग, ट्रेसिंग और मॉनिटरिंग के लिए अलग उपकरण हैं। कोई "सुनहरा साधन" नहीं है जो आपकी सभी जरूरतों को पूरा करेगा।

यह समझने के लिए कि किस उपकरण की आवश्यकता है, क्या निगरानी करना है, कौन से लॉग का उपयोग करना है, कौन सी लॉग आवश्यकताओं के लिए, आपको निश्चित रूप से SLI / SLO - सेवा स्तर संकेतक / सेवा स्तर उद्देश्य का उल्लेख करना चाहिए। आपको यह जानना होगा कि आपके ग्राहकों और आपके व्यवसाय के लिए क्या महत्वपूर्ण है, वे किन संकेतकों को देखते हैं।

एक हफ्ते बाद, SKOLKOVO HighLoad ++ 2019 की मेजबानी करेगा। 7 नवंबर की शाम में, इवान लेटेंको आपको बताएगा कि वह रेडिस के साथ ठेस पर कैसे रहता है, और कुल मिलाकर विभिन्न विषयों पर कार्यक्रम में 150 रिपोर्टें हैं ।

यदि आपको HighLoad ++ 2019 के लाइव होने में समस्या आ रही है, तो हमारे पास अच्छी खबर है। इस वर्ष सम्मेलन तीन शहरों में एक साथ आयोजित किया जाएगा - मास्को, नोवोसिबिर्स्क और सेंट पीटर्सबर्ग में। उसी समय। यह कैसे होगा और वहां कैसे पहुंचा जाएगा - इस घटना के एक अलग प्रोमो पेज पर पता करें ।