यूरी बुशमेलेव "लॉग एकत्र करने और वितरित करने के क्षेत्र में एक रेक का मानचित्र" - रिपोर्ट की प्रतिलेख

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मैं आपको दिखाऊंगा कि हमने लाजदा में यह कैसे किया और यह सब कैसे शुरू हुआ।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

धाराप्रवाह। सबसे पहले, मैं उससे पिछली नौकरी में मिला था, और वह भी समय-समय पर वहाँ गिरता था। दूसरे, यह वही है, केवल प्रोफ़ाइल में.

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

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

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

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

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

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

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

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

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

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

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

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

इसके बाद, अन्य खोजें जो हमने इस दौरान की हैं।

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

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

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

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

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

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

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

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

और फिर से एक रेक! हमारी दो बिक्री होने वाली हैं। हम 6 मिलियन पोस्ट से आगे बढ़ गए हैं। हमारे पास ग्रेलॉग को चबाने का समय नहीं है। किसी तरह तुम्हें फिर से जीवित रहना होगा।

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

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

ग्रेलॉग से मेट्रिक्स एकत्र करें।

एक दर सीमा बनाएं ताकि हमारे पास एक पागल एपीआई हो जो हमारे बैंडविड्थ और बाकी सभी चीज़ों को ख़त्म न कर दे।

और अंत में, डेवलपर्स के साथ किसी प्रकार के एसएलए पर हस्ताक्षर करें ताकि हम उतनी सेवा कर सकें। ज्यादा लिखो तो माफ़ करना.

और दस्तावेज लिखें.

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

सवाल.

सवाल: उन्होंने न लेने का निर्णय क्यों लिया... (फ़ाइलबीट?)

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

सवाल: आप एचडीएफएस पर लॉग क्यों नहीं लिखते?

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

सवाल: एक कॉलम प्रारूप अधिक उपयुक्त होगा.

जवाब: मैं समझता हूँ। हम दोनों हाथों से "के लिए" हैं।

सवाल: आप rsyslog को लिखें। टीसीपी और यूडीपी दोनों वहां उपलब्ध हैं। लेकिन अगर यूडीपी है, तो आप डिलीवरी की गारंटी कैसे देते हैं?

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

सवाल: जब एपीआई लॉग में कुछ संदेश उत्पन्न करता है और माइक्रोसर्विसेज पर नियंत्रण स्थानांतरित करता है, तो क्या आपने इस समस्या का सामना किया है कि विभिन्न माइक्रोसर्विसेज से संदेश गलत क्रम में आते हैं? इस वजह से भ्रम की स्थिति पैदा होती है.

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

सवाल: टाइमस्टैम्प मिलीसेकेंड के हिसाब से भिन्न हो सकता है।

जवाब: टाइमस्टैम्प एपीआई द्वारा ही उत्पन्न होता है। वास्तव में, यही संपूर्ण मुद्दा है। हमारे पास एनटीपी है। एपीआई संदेश में पहले से ही एक टाइमस्टैम्प उत्पन्न करता है। इसे rsyslog द्वारा नहीं जोड़ा गया है.

सवाल: डेटा केंद्रों के बीच बातचीत बहुत स्पष्ट नहीं है। डेटा सेंटर के ढांचे के भीतर, यह स्पष्ट है कि लॉग कैसे एकत्र और संसाधित किए गए थे। डेटा केंद्रों के बीच परस्पर क्रिया कैसी है? या क्या प्रत्येक डेटा सेंटर अपना जीवन जीता है?

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

सवाल: क्या आपको असामान्य स्थितियों के दौरान वहां से लॉग मिलते हैं?

जवाब: आप वहां (फाइल स्टोरेज में) जाकर देख सकते हैं।

सवाल: आप कैसे निगरानी रखते हैं कि आप लॉग न खोएं?

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

सवाल: इलास्टिक्स खोज में, आप अतिरेक के साथ लॉग संग्रहीत करते हैं। आपके पास कितनी प्रतिकृतियाँ हैं?

जवाब: एक प्रतिकृति.

सवाल: क्या यह सिर्फ एक पंक्ति है?

जवाब: यह गुरु और प्रतिकृति है. डेटा डुप्लिकेट में संग्रहीत है।

सवाल: क्या आपने rsyslog बफ़र के आकार में किसी तरह बदलाव किया?

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

सवाल: क्या आप टूटा हुआ JSON लिखते हैं?

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

सवाल: काफ्का क्यों? क्या आपने RabbitMQ आज़माया है? ग्रेलॉग इतने भार के तहत नहीं जुड़ता है?

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

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

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

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

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

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

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

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

स्रोत: www.habr.com