यूरी बुशमेले "लॉग संग्रह और वितरण क्षेत्र पर रेक मैप" - रिपोर्ट की प्रतिलिपि

लॉग सिस्टम का एक महत्वपूर्ण हिस्सा हैं, जिससे आप समझ सकते हैं कि यह काम करता है (या काम नहीं करता है), जैसा कि अपेक्षित था। माइक्रोसवर्क वास्तुकला की स्थितियों में, लॉग के साथ काम एक विशेष ओलंपियाड का एक अलग अनुशासन बन जाता है। आपको तुरंत प्रश्नों का एक गुच्छा हल करना होगा:

• कैसे आवेदन से लॉग लिखने के लिए;
• लॉग लिखने के लिए कहाँ;
• भंडारण और प्रसंस्करण के लिए लॉग कैसे वितरित करें;
• लॉग को कैसे प्रोसेस और स्टोर करें।

कंटेनरीकरण प्रौद्योगिकियों का उपयोग, जो अब लोकप्रिय है, समस्या को हल करने के लिए विकल्पों के क्षेत्र में रेक के शीर्ष पर रेत जोड़ता है।

यूरी बुशमेलेव की रिपोर्ट के इस डिकोडिंग के बारे में "लॉग के संग्रह और वितरण के क्षेत्र पर मानचित्र रेक"

कौन परवाह करता है, कृपया, बिल्ली के नीचे।

मेरा नाम यूरी बुशमेलेव है। मैं लाजदा में काम करता हूं। आज मैं इस बारे में बात करूंगा कि हमने अपने लॉग कैसे किए, हमने उन्हें कैसे एकत्र किया, और हम वहां क्या लिखते हैं।

हम कहाँ से हैं? हम कौन हैं? लाज़ाडा दक्षिण पूर्व एशिया में छह देशों में नंबर 1 ऑनलाइन स्टोर है। इन सभी देशों को डेटा केंद्रों द्वारा वितरित किया जाता है। अब 4 डेटा सेंटर हैं। यह महत्वपूर्ण क्यों है? क्योंकि कुछ निर्णय इस तथ्य के कारण थे कि केंद्रों के बीच बहुत कमजोर संबंध है। हमारे पास एक माइक्रोसैस आर्किटेक्चर है। मुझे यह जानकर आश्चर्य हुआ कि हमारे पास पहले से ही 80 माइक्रोसर्विसेज हैं। जब मैंने लॉग के साथ कार्य शुरू किया था, तो केवल 20 थे। प्लस, पीएचपी विरासत का एक बड़ा हिस्सा है, जिसे आपको भी साथ रखना होगा। यह सब एक पल में पूरे सिस्टम में 6 मिलियन से अधिक संदेश प्रति मिनट उत्पन्न करता है। आगे मैं दिखाऊंगा कि हम कैसे इसके साथ रहना चाह रहे हैं और ऐसा क्यों है।

हमें किसी तरह इन 6 मिलियन संदेशों के साथ रहने की आवश्यकता है। हमें उनके साथ क्या करना चाहिए? 6 मिलियन संदेश जो आपको चाहिए:

• आवेदन से भेजें
• प्रसव के लिए स्वीकार करें
• विश्लेषण और भंडारण के लिए वितरित करें।
• विश्लेषण करना
• किसी तरह दुकान।

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

इसके साथ कैसे रहना है? अब मैं संक्षेप में विकल्पों के क्षेत्र का वर्णन करूंगा - सामान्य रूप से यह समस्या कैसे हल की जाती है। लॉग को इकट्ठा करने, स्थानांतरित करने और संग्रहीत करने की समस्या को कैसे हल किया जाए।

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

उसी स्थिति के बारे में लॉग के संग्रह के साथ। इस विशेष भाग को हल करने के लिए कई विकल्प नहीं हैं। पहले से ही अधिक हैं, लेकिन इतने सारे नहीं।

लेकिन वितरण और बाद के विश्लेषण के साथ - विविधताओं की संख्या में विस्फोट होने लगता है। मैं अब प्रत्येक विकल्प का वर्णन नहीं करूंगा। मुझे लगता है कि मुख्य विकल्प हर किसी के द्वारा सुने जाते हैं जो विषय में रुचि रखते थे।

मैं दिखाऊंगा कि हमने इसे लजाडा में कैसे किया, और वास्तव में यह सब कैसे शुरू हुआ।

एक साल पहले, मैं लज़ादा आया, और उन्होंने मुझे लॉग्स के बारे में एक प्रोजेक्ट भेजा। यह इस तरह था। आवेदन से लॉग को stdout और stderr को लिखा गया था। उन्होंने सब कुछ फैशनेबल तरीके से किया। लेकिन तब डेवलपर्स ने इसे मानक प्रवाह से बाहर फेंक दिया, और फिर वहां के बुनियादी ढांचे के विशेषज्ञ इसे किसी तरह से सुलझा लेंगे। इन्फ्रास्ट्रक्चरल विशेषज्ञों और डेवलपर्स के बीच भी ऐसे रिलीवर होते हैं जिन्होंने कहा: "उह ... ठीक है, चलो उन्हें एक शेल के साथ एक फाइल में लपेटें, बस इतना ही।" और चूंकि यह सब कंटेनर में है, इसलिए उन्होंने इसे कंटेनर में ही लपेट दिया, कैटलॉग को अंदर डाउनलोड किया और इसे वहां रख दिया। मुझे लगता है कि यह सभी के लिए लगभग स्पष्ट है कि यह क्या आया।

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

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

यदि आप ऊपर से दूर से देखते हैं तो यह कैसा दिखता है। यह मत करो! यहां, संख्या तुरंत समस्या क्षेत्रों को इंगित करती है। वास्तव में उनमें से अधिक हैं, लेकिन 6 वास्तव में काफी समस्याग्रस्त हैं, जिसके साथ आपको कुछ करने की आवश्यकता है। मैं अब उनके बारे में अलग से बात करूंगा।

यहां (1,2,3) हम फाइलें लिख रहे हैं और तदनुसार, यहां एक साथ तीन रेक हैं।

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

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

(४) हमारे पास अलग-अलग प्रारूप थे और विभिन्न एपीआई में थे। वे थोड़े अलग थे, लेकिन regexp को अलग तरह से लिखा जाना था। चूंकि यह सब पपेट द्वारा नियंत्रित किया गया था, इसलिए उनके तिलचट्टे के साथ कक्षाओं का एक बड़ा बंडल था। इसके अलावा, td- एजेंट ज्यादातर समय स्मृति, बेवकूफ खा सकता है, यह सिर्फ दिखावा कर सकता है कि यह काम करता है, और कुछ भी नहीं। बाहर, यह समझना असंभव था कि वह कुछ नहीं कर रहा था। सबसे अच्छा, वह गिर जाएगा, और कोई उसे बाद में उठाएगा। अधिक सटीक रूप से, अलर्ट आ जाएगा, और कोई अपने हाथों से ऊपर जाएगा।

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

हम ये सवाल पूछने लगे। हमने दोषियों की तलाश नहीं करने का फैसला किया।

लेकिन कुछ करने की जरूरत है! स्पष्ट बात मानकों को निर्धारित करना है। हमारे पास पहले से ही कुछ मानक थे। कुछ हम थोड़ी देर बाद मिले। सौभाग्य से, उस समय सभी API के लिए एक समान लॉग प्रारूप पहले से ही स्वीकृत था। यह सीधे सेवाओं की बातचीत के लिए मानकों में लिखा गया है। तदनुसार, जो लोग लॉग प्राप्त करना चाहते हैं, उन्हें इस प्रारूप में लिखना चाहिए। यदि कोई इस प्रारूप में लॉग नहीं लिखता है, तो हम कुछ भी गारंटी नहीं देते हैं।

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

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

हमने समस्या का समाधान कैसे शुरू किया? मुख्य रेक td- एजेंट के साथ था। यह स्पष्ट नहीं था कि लॉग कहां जा रहे थे। क्या वे वितरित किए गए हैं? क्या वे जा रहे हैं? वे बिल्कुल कहाँ हैं? इसलिए, पहले आइटम को td-agent को बदलने का निर्णय लिया गया था। मैंने संक्षेप में विकल्प दिया कि इसके साथ क्या प्रतिस्थापित किया जाए।

Fluentd। सबसे पहले, मैं एक पिछली नौकरी में उसके पास आया, और वह समय-समय पर वहां गिर गया। दूसरे, यह केवल प्रोफाइल में है।

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

इस राशि में सभी syslogs sysadmin के लिए स्पष्ट समाधान है (syslog-ng / rsyslog / nxlog)।

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

इसलिए, चुनाव वास्तव में syslog- एनजी और rsyslog के बीच चुनाव के लिए नीचे आया। वह बस rsyslog की ओर झुक गया क्योंकि हमारे पास पहले से ही कठपुतली में rsyslog के लिए कक्षाएं थीं, और मुझे उनके बीच कोई स्पष्ट अंतर नहीं मिला। सिसलॉग क्या है, सिसलॉग क्या है। हां, किसी के पास बदतर दस्तावेज हैं, किसी के पास बेहतर हैं। वह जानता है कि कैसे, और वह - एक अलग तरीके से।

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

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

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

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

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

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

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

क्या समस्याएं हैं? इस तथ्य से समस्याएं पैदा हुईं कि हमने खोजा (SUDDENLY!) कि हमारे लाइव एपीआई प्रति सेकंड 50k संदेश लिखते हैं। यह बिना स्टेजिंग के केवल एक लाइव एपीआई है। और ग्रेलाग हमें प्रति सेकंड केवल 12 हजार संदेश दिखाता है। और एक वाजिब सवाल खड़ा हुआ, लेकिन बचे कहां हैं? जिससे हमने यह निष्कर्ष निकाला कि ग्रेगल केवल सामना नहीं कर सकता है। उन्होंने देखा, और, वास्तव में, एलियस्टिक्स खोज के साथ ग्रेलॉग ने इस धारा में महारत हासिल नहीं की।

इसके अलावा, अन्य खोजें जो हमने प्रक्रिया में बनाई थीं।

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

कतारों के आकार की निगरानी करना आवश्यक है, जो इस रेक पर कदम न रखने में मदद करता है। जब हम संदेश खोना शुरू करते हैं, तो हम निगरानी कर सकते हैं। दूसरे, हम यह देख सकते हैं कि सिद्धांत रूप में हमें वितरण की समस्या है।

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

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

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

लॉगस्टैश और ग्रेलॉग के साथ यह हिस्सा, यह वास्तव में चढ़ता है। इसलिए, हमें इससे छुटकारा पाना चाहिए। आपको एक चीज चुननी है।

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

नए ग्रेलॉग में वास्तव में क्या शामिल है। हमने सिर्फ डॉकटर में सब कुछ दर्ज किया। हमने सर्वरों का एक समूह लिया, तीन काफ्का उदाहरणों को लुढ़काया, 7 ग्रेगॉल्स सर्वर संस्करण 2.3 (क्योंकि मैं एलियस्टैकरस संस्करण 5 चाहता था)। यह सब उठाया HDD से छापे पर। हमने प्रति सेकंड 100 हजार संदेशों तक की अनुक्रमण दर देखी। हमने आंकड़ा देखा कि प्रति सप्ताह 140 टेराबाइट डेटा।

और फिर से एक रेक! दो बिक्री आ रही है। हम 6 मिलियन संदेशों के लिए चले गए हैं। हम पर ग्रेगल को चबाने का समय नहीं है। किसी तरह हमें फिर से बचना होगा।

हम इस तरह बच गए। हमने कुछ और सर्वर और SSD जोड़े। फिलहाल, हम इस तरह से रहते हैं। अब हम पहले से ही प्रति सेकंड 160k संदेशों को चबा रहे हैं। हम अभी तक सीमा तक नहीं पहुंचे हैं, इसलिए यह अभी तक स्पष्ट नहीं है कि हम वास्तव में इससे कितना बाहर निकल सकते हैं।

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

Graylog.

rate limit , API, bandwidth .

, - SLA c , . , .

.

, , . -, . -, syslog — . -, rsyslog , . .

.

: - … (filebeat?)

: . . API , , . pipe. : « , , »? , , : « , ».

: HDFS?

: . , , , , long term solution.

: .

: . "" .

: rsyslog. TCP, UDP. UDP, ?

: . , , . , : « , - , - », «! , , , .» . , ? , ? best effort. , 100% . . .

: API - , , ? - .

: , . . , . , API . rsyslog . API , , timestamp . Graylog, timestamp. .

: Timestamp .

: Timestamp API. , , . NTP. API timestamp . rsyslog .

: . , . ? ?

: . - . , . . Log Relay. Rsyslog . . . . . . , (), Graylog. storage. , , . . .

: ?

: ( ) .

: , ?

: , . . , Go API, . , socket. . . socket. , . . , . prometheus, Grafana . . , .

: elasticsearch . ?

: .

: ?

: . .

: rsyslog - ?

: unix socket. 128 . . . , 128 . , , , , . , . .

c : JSON?

: JSON relay, . Graylog, JSON . , , rsyslog. issue, .

c : Kafka? RabbitMQ? Graylog ?

: Graylog . Graylog . . . , , . rsyslog elasticsearch Kibana. . , Graylog Kibana. Logstash . , rsyslog. elasticsearch. Graylog - . . .

Kafka. . , , . . , , . RabbitMQ… c RabbitMQ. RabbitMQ . , . , . . . Graylog AMQP 0.9, rsyslog AMQP 1.0. , , . . Kafka. . omkafka rsyslog, , , rsyslog. .

प्रश्न : क्या आप काफ्का का उपयोग करते हैं क्योंकि आपके पास यह था? किसी अन्य उद्देश्य के लिए इस्तेमाल नहीं किया?

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

प्रश्न : कुर्सियां ​​के साथ यह शर्मिंदगी क्यों जरूरी है? क्या आपने कंटेनर के लिए syslog लॉग ड्राइवर का उपयोग करने की कोशिश की है?

उत्तर : उस समय जब हमने यह प्रश्न पूछा था, तो हमारा कर्ता के साथ तनावपूर्ण संबंध था। यह डॉकटर 1.0 या 0.9 था। खुद डॉकर अजीब थे। दूसरे, यदि आप लॉग को इसमें शामिल कर लेते हैं ... मुझे इस बात का असंदिग्ध संदेह है कि वह सभी लॉग को स्वयं के माध्यम से, docker डेमन के माध्यम से पास करता है। यदि हमारे पास एक एपीआई पागल हो रहा है, तो बाकी एपीआई इस तथ्य में फंस गए हैं कि वे स्टडआउट और स्टडर नहीं भेज सकते हैं। मुझे नहीं पता कि यह कहां होगा। मुझे इस स्तर पर संदेह है कि आपको इस स्थान पर docker syslog ड्राइवर का उपयोग करने की आवश्यकता नहीं है। हमारे कार्यात्मक परीक्षण विभाग के पास लॉग्स के साथ अपना स्वयं का ग्रेलेग क्लस्टर है। वे डॉक लॉग-ड्राइवर का उपयोग करते हैं और वहां सब कुछ ठीक लगता है। लेकिन वे जीईएलएफ को तुरंत ग्रेलॉग लिखते हैं। हम उस क्षण में जब यह सब ऊपर था, हमें बस काम करने की जरूरत थी। शायद बाद में, जब कोई आता है और कहता है कि यह सामान्य रूप से सौ वर्षों से काम कर रहा है, तो हम कोशिश करेंगे।

प्रश्न : आप rsyslog पर डेटा केंद्रों के बीच वितरण करते हैं। काफ्का पर क्यों नहीं?

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