कैसे हम Tsian लॉग के टेराबाइट्स नामित

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

हमने कहां से शुरुआत की?

पिछले कुछ वर्षों में, cian.ru पर भार बहुत तेज़ी से बढ़ा है, और 2018 की तीसरी तिमाही तक, संसाधन यातायात प्रति माह 11.2 मिलियन अद्वितीय उपयोगकर्ताओं तक पहुंच गया। उस समय, महत्वपूर्ण क्षणों में, हमने 40% लॉग खो दिए थे, जिसके कारण हम घटनाओं से जल्दी से नहीं निपट सकते थे और उन्हें हल करने में बहुत समय और प्रयास खर्च करते थे। हम अक्सर समस्या का कारण नहीं खोज पाए, और कुछ समय बाद इसकी पुनरावृत्ति हुई। यह नरक था जिसके साथ आपको कुछ करना था।

उस समय, हमने लॉग्स को स्टोर करने के लिए विशिष्ट इंडेक्स सेटिंग्स के साथ ElasticSearch संस्करण 5.5.2 के साथ 10 डेटा नोड्स के एक क्लस्टर का उपयोग किया था। यह एक लोकप्रिय और सस्ती समाधान के रूप में एक साल से अधिक समय पहले पेश किया गया था: तब लॉग स्ट्रीम इतनी बड़ी नहीं थी, गैर-मानक कॉन्फ़िगरेशन का आविष्कार करने का कोई मतलब नहीं था।

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

विकास की समस्याएं

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

यह स्केलिंग थी जिसने हमें इस तथ्य तक पहुंचाया कि क्लस्टर वास्तव में बेकाबू हो गया। जब लॉग प्रति सेकंड 20 हजार संदेशों की गति से आने लगे, तो लगातार बेकार रोटेशन ने शार्क की संख्या 6 हजार तक बढ़ा दी, और एक नोड में 600 से अधिक शार्क के लिए जिम्मेदार था।

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

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

हम एक लक्ष्य निर्धारित करते हैं - लॉग के नुकसान को पूरी तरह से खत्म करने और बल के ऐंठन के दौरान ELK क्लस्टर में उनकी डिलीवरी के समय को अधिकतम 15 मिनट तक कम करने के लिए (हम भविष्य में इस आंकड़े पर आंतरिक KPI के रूप में भरोसा करते हैं)।

नया रोटेशन तंत्र और गर्म-गर्म नोड्स

हमने 5.5.2 से 6.4.3 तक ElasticSearch के संस्करण को अपडेट करके क्लस्टर परिवर्तन की शुरुआत की। एक बार फिर, संस्करण 5 का एक क्लस्टर हमारे पास चला गया, और हमने इसे चुकाने का फैसला किया और पूरी तरह से अपडेट किया - अभी भी कोई लॉग नहीं हैं। इसलिए हमने कुछ ही घंटों में यह परिवर्तन कर दिया।

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

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

क्लस्टर अनुकूलन

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

उदाहरण के लिए, रोटेशन को कॉन्फ़िगर करने के लिए:

urator-elk-rollover.yaml --- actions:   1:     action: rollover     options:       name: "nginx_write"       conditions:         max_docs: 100000000   2:     action: rollover     options:       name: "python_error_write"       conditions:         max_docs: 10000000 

रोलओवर उर्फ ​​की अनुपस्थिति में, एक त्रुटि हुई:

 ERROR   alias "nginx_write" not found. ERROR   Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write". 

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

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

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

लॉग पुनर्वितरण

इस वर्ष के सितंबर में, हमने अभी भी मोनोलिथ को देखना जारी रखा, क्लस्टर पर लोड बढ़ गया, और लॉग स्ट्रीम प्रति सेकंड 30 हजार संदेश आ रहा था।



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

• गर्म नोड्स के लिए: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot1 के लिए 3 और Hot2 के लिए 3)।
  
• गर्म नोड्स के लिए: E3-1230 v6 / 4Tb SSD / 32 Gb x 4।
  

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

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

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

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

भविष्य की योजना

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

अक्टूबर 2019 में, cian.ru यातायात प्रति माह 15.3 मिलियन अद्वितीय उपयोगकर्ताओं तक पहुंच गया। यह लॉग के वितरण के लिए वास्तु समाधान का एक गंभीर परीक्षण था।

अब हम ElasticSearch को वर्जन 7 में अपग्रेड करने की तैयारी कर रहे हैं। हालांकि, इसके लिए हमें ElasticSearch में कई इंडेक्स की मैपिंग को अपडेट करना होगा, क्योंकि वे 5.5 वर्जन से चले गए और वर्जन 6 में अपग्रेड किए गए घोषित किए गए (वे केवल वर्जन 7 में मौजूद नहीं हैं)। और इसका मतलब यह है कि अद्यतन करने की प्रक्रिया में निश्चित रूप से कुछ बल होगा, जो हमें समय के बिना लॉग के छोड़ देगा। 7 संस्करणों में से, हम एक बेहतर इंटरफ़ेस और नए फ़िल्टर के साथ किबाना की ओर देख रहे हैं।

हमने मुख्य लक्ष्य प्राप्त किया: हमने लॉग्स को खोना बंद कर दिया और प्रति माह 2-3 बूंद प्रति सप्ताह सेवा के काम के कुछ घंटों के लिए इन्फ्रास्ट्रक्चर क्लस्टर के डाउनटाइम को कम कर दिया। उत्पादन पर यह सब काम लगभग अदृश्य है। हालांकि, अब हम यह निर्धारित कर सकते हैं कि हमारी सेवा के साथ क्या हो रहा है, हम जल्दी से इसे एक शांत मोड में कर सकते हैं और चिंता न करें कि लॉग खो जाएगा। सामान्य तौर पर, हम संतुष्ट हैं, खुश हैं और नए कारनामों की तैयारी कर रहे हैं, जिनके बारे में हम बाद में बात करेंगे।