युरी बुशमेलेभ "लगहरू सङ्कलन र वितरणको क्षेत्रमा रेकको नक्सा" - रिपोर्टको ट्रान्सक्रिप्ट

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

• एप्लिकेसनबाट लगहरू कसरी लेख्ने;
• कहाँ लगहरू लेख्न;
• भण्डारण र प्रशोधनका लागि लगहरू कसरी डेलिभर गर्ने;
• कसरी लगहरू प्रशोधन गर्ने र भण्डार गर्ने।

हाल लोकप्रिय कन्टेनराइजेशन टेक्नोलोजीहरूको प्रयोगले समस्या समाधान गर्न विकल्पहरूको क्षेत्रमा रेकको शीर्षमा बालुवा थप्छ।

युरी बुशमेलेभको रिपोर्ट "लगहरू सङ्कलन र वितरण गर्ने क्षेत्रमा रेकहरूको नक्सा" को ट्रान्सक्रिप्ट वास्तवमा यही हो।

जो कोही इच्छुक को लागी, बिरालो हेर्नुहोस्।

मेरो नाम युरी बुशमेलेभ हो। Lazada मा काम गर्नुहुन्छ आज म हामीले हाम्रो लगहरू कसरी बनायौं, हामीले तिनीहरूलाई कसरी सङ्कलन गर्यौं, र हामीले त्यहाँ के लेख्यौं भन्ने बारेमा कुरा गर्नेछु।

हामी कहाँबाट हौं? हामी को हौं? Lazada दक्षिणपूर्व एशियाका छ देशहरूमा नम्बर 1 अनलाइन खुद्रा विक्रेता हो। यी सबै देशहरू हाम्रा डाटा केन्द्रहरू बीच वितरित छन्। हाल जम्मा ४ वटा डाटा केन्द्रहरू छन्। यो किन महत्त्वपूर्ण छ? किनभने केही निर्णयहरू केन्द्रहरू बीचको धेरै कमजोर सम्बन्ध रहेको तथ्यका कारण थिए। हामीसँग माइक्रोसर्भिस आर्किटेक्चर छ। हामीसँग पहिले नै 4 माइक्रोसर्भिसहरू छन् भनी थाहा पाउँदा म छक्क परें। जब मैले लगहरूसँग कार्य सुरु गरें, त्यहाँ केवल 80 जना थिए। साथै त्यहाँ PHP विरासतको बरु ठूलो टुक्रा छ, जसलाई मैले पनि बाँच्न र राख्नु पर्छ। यो सबैले हाल प्रणालीको लागि प्रति मिनेट 20 मिलियन भन्दा बढी सन्देशहरू उत्पन्न गर्दछ। अर्को म देखाउनेछु कि हामी यससँग कसरी बाँच्न कोशिस गर्दैछौं, र यो किन हो।

तपाईंले यी 6 मिलियन सन्देशहरूसँग कुनै न कुनै रूपमा बाँच्नु पर्छ। हामीले तिनीहरूलाई के गर्नुपर्छ? तपाईंलाई आवश्यक 6 मिलियन सन्देशहरू:

• एपबाट पठाउनुहोस्
• डेलिभरीको लागि स्वीकार गर्नुहोस्
• विश्लेषण र भण्डारणको लागि डेलिभर गर्नुहोस्।
• विश्लेषण गर्नुहोस्
• यसलाई कुनै न कुनै रूपमा भण्डार गर्नुहोस्।

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

यससँग कसरी बाँच्ने? अब म छोटकरीमा विकल्पहरूको क्षेत्र वर्णन गर्नेछु - कसरी यो समस्या सामान्यतया हल हुन्छ। लगहरू सङ्कलन, प्रसारण र भण्डारणको समस्या कसरी समाधान गर्ने।

आवेदनबाट कसरी लेख्ने? यो स्पष्ट छ कि त्यहाँ विभिन्न तरिकाहरू छन्। विशेष गरी, त्यहाँ सबै भन्दा राम्रो अभ्यास छ, जस्तै हाम्रो फैशनेबल साथीहरूले हामीलाई बताउँछन्। हाम्रा हजुरबुबाले भनेझैं पुरानो विद्यालय दुई प्रकारका हुन्छन्। त्यहाँ अन्य तरिकाहरू छन्।

लगहरू सङ्कलन गर्ने अवस्था लगभग उस्तै छ। यो विशेष भाग समाधान गर्न धेरै विकल्पहरू छैनन्। तिनीहरूमध्ये पहिले नै धेरै छन्, तर अझै धेरै छैनन्।

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

म तपाइँलाई देखाउनेछु कि हामीले यो Lazada मा कसरी गर्यौं, र यो सबै वास्तवमा कसरी सुरु भयो।

एक वर्ष पहिले म Lazada आएँ र लग को बारे मा एक परियोजना मा पठाइयो। यो केहि यस्तो थियो। आवेदन लग stdout र stderr मा लेखिएको थियो। सबै कुरा फैशनेबल तरिकामा गरिएको थियो। तर त्यसपछि विकासकर्ताहरूले यसलाई मानक प्रवाहबाट बाहिर निकाले, र त्यसपछि कुनै न कुनै रूपमा पूर्वाधार विशेषज्ञहरूले यसलाई पत्ता लगाउनेछन्। पूर्वाधार विशेषज्ञहरू र विकासकर्ताहरू बीच, त्यहाँ रिलीजकर्ताहरू पनि छन् जसले भने: "उह... ठीक छ, तिनीहरूलाई खोलको साथ फाइलमा बेरौं, र यो हो।" र यो सबै कन्टेनरमा भएको हुनाले, तिनीहरूले यसलाई कन्टेनरमा नै बेरे, क्याटलग भित्र म्याप गरे र त्यहाँ राखे। मलाई लाग्छ कि यो के आयो सबैलाई यो धेरै स्पष्ट छ।

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

यसपछि हामीले के गर्‍यौं? हामीले काफ्कालाई पठायौं। त्यसपछि काफ्काका आधा लगहरू लगस्टासमा उड्यो। लगहरूको अर्को आधा भाग विभाजित गरियो। कोही एउटा ग्रेलोगमा उडे, कोही अर्को ग्रेलोगमा। नतिजाको रूपमा, यो सबै एक Elasticsearch क्लस्टरमा गए। त्यो हो, यो सबै गडबड त्यहाँ समाप्त भयो। त्यसो नगर्नुहोस्!

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

यहाँ (1,2,3) हामी फाइलहरू लेख्छौं र, तदनुसार, यहाँ एकै पटक तीन रेकहरू छन्।

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

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

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

(6) र सबैभन्दा रद्दीटोकरी र फोहोर इलास्टिक खोज थियो। किनभने यो पुरानो संस्करण थियो। किनभने त्यो बेला हामीसँग समर्पित गुरुहरू थिएनन्। हामीसँग विषम लगहरू थिए जसका फिल्डहरू ओभरल्याप हुन सक्छन्। बिभिन्न अनुप्रयोगहरूबाट फरक लगहरू एउटै फिल्ड नामहरूसँग लेख्न सकिन्छ, तर भित्र फरक डाटा हुन सक्छ। त्यो हो, एउटा लग फिल्डमा पूर्णांकको साथ आउँछ, उदाहरणका लागि, स्तर। अर्को लग लेवल फिल्डमा स्ट्रिङको साथ आउँछ। स्थिर म्यापिङको अभावमा, यो यस्तो अद्भुत कुरा हो। यदि, elasticsearch मा अनुक्रमणिका घुमाएपछि, स्ट्रिङको साथ सन्देश पहिले आउँछ, त्यसपछि हामी सामान्य रूपमा बाँच्दछौं। तर यदि पहिलो इन्टिजरबाट आयो भने, त्यसपछि स्ट्रिङबाट आएका सबै सन्देशहरू मात्र खारेज हुन्छन्। किनभने फिल्ड प्रकार मेल खाँदैन।

हामीले यी प्रश्नहरू सोध्न थाल्यौं। हामीले दोषीलाई नखोज्ने निर्णय गर्‍यौं।

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

अर्को, म रेकर्डिङ, डेलिभर र लग सङ्कलन विधिहरूको लागि एक एकीकृत मानक सिर्जना गर्न चाहन्छु। वास्तवमा, तिनीहरूलाई कहाँ लेख्ने, र तिनीहरूलाई कसरी डेलिभर गर्ने। परियोजनाहरूले एउटै पुस्तकालय प्रयोग गर्दा आदर्श अवस्था हो। त्यहाँ Go को लागी छुट्टै लगिङ लाइब्रेरी छ, र PHP को लागी छुट्टै लाइब्रेरी छ। हामीसँग भएका सबैले प्रयोग गर्नुपर्छ। अहिले म भन्न चाहन्छु कि हामी यसमा ८० प्रतिशत सफल छौं । तर कतिपयले क्याक्टस खान जारी राख्छन्।

र त्यहाँ (स्लाइडमा) "लगहरूको डेलिभरीको लागि SLA" मुश्किलले देखा पर्न थाल्छ। यो अझै अवस्थित छैन, तर हामी यसमा काम गरिरहेका छौं। किनकि यो धेरै सुविधाजनक छ जब पूर्वाधारले भन्छ कि यदि तपाईले यस्तो र त्यस्तो ठाउँमा यस्तो र त्यस्तो ढाँचामा लेख्नु भयो र प्रति सेकेन्ड N सन्देशहरू नहोस्, तब हामी सम्भवतः यसलाई त्यस्तो ठाउँमा पुर्‍याउनेछौं। यसले टाउको दुखाइमा धेरै राहत दिन्छ। यदि त्यहाँ एक SLA छ, तब यो बिल्कुल अद्भुत छ!

हामीले कसरी समस्या समाधान गर्न सुरु गर्यौं? मुख्य समस्या td-एजेन्ट संग थियो। हाम्रो लगहरू कहाँ गयो थाहा भएन। के तिनीहरू डेलिभर हुन्छन्? के तिनीहरू जाँदैछन्? जे भए पनि तिनीहरू कहाँ छन्? त्यसकारण, पहिलो बिन्दु td-एजेन्ट प्रतिस्थापन गर्ने निर्णय गरियो। मैले यसलाई यहाँ केसँग प्रतिस्थापन गर्ने विकल्पहरू संक्षिप्त रूपमा रेखांकित गरेको छु।

प्रवाहित। पहिले, मैले उसलाई अघिल्लो काममा भेटें, र उनी पनि समय-समयमा त्यहाँ पसे। दोस्रो, यो एउटै कुरा हो, केवल प्रोफाइलमा।

फाइलबिट। यो हाम्रो लागि कसरी सुविधाजनक थियो? किनभने यो Go मा छ, र हामीसँग Go मा धेरै विशेषज्ञता छ। तदनुसार, यदि केहि भयो भने, हामी कुनै न कुनै रूपमा यसलाई आफ्नो लागि थप्न सक्छौं। त्यही भएर हामीले लिएका छैनौं । ताकि त्यहाँ आफ्नो लागि पुन: लेख्न सुरु गर्न कुनै प्रलोभन पनि छैन।

प्रणाली प्रशासकको लागि स्पष्ट समाधान यो मात्रा (syslog-ng/rsyslog/nxlog) मा सबै प्रकारका syslogs हो।

वा तपाईंको आफ्नै केहि लेख्नुहोस्, तर हामीले यसलाई खारेज गर्यौं, साथै फाइलबिट। यदि तपाइँ केहि लेख्नुहुन्छ भने, यो व्यापारको लागि उपयोगी केहि लेख्नु राम्रो हो। लगहरू डेलिभर गर्न, यो केहि तयार-बनाउन राम्रो छ।

त्यसकारण, छनोट वास्तवमा syslog-ng र rsyslog बीचको छनोटमा आयो। म rsyslog तिर झुकाएँ किनभने हामीसँग पपेटमा rsyslog को लागि कक्षाहरू पहिले नै थिए, र मैले तिनीहरू बीच स्पष्ट भिन्नता फेला पारेन। syslog के हो, syslog के हो। हो, कसैको नराम्रो कागजात छ, कसैसँग राम्रो छ। यो एकले यसलाई यसरी गर्न सक्छ, र अर्कोले यसलाई फरक तरिकाले गर्न सक्छ।

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

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

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

फाइल किन छैन? किनभने सबैले पढेका छन् Badushechka बारेमा लेख, जसले डकरमा फाइल फर्वार्ड गर्ने प्रयास गर्यो, र यो पत्ता लाग्यो कि rsyslog पुन: सुरु गरेपछि, फाइल वर्णनकर्ता परिवर्तन भयो, र डकरले यो फाइल हराएको छ। यसले अरू केहि खुला राख्छ, तर सकेट होइन जहाँ उनीहरूले लेखिरहेका छन्। हामीले निर्णय गर्यौं कि हामी यो समस्याको वरिपरि काम गर्नेछौं, र एकै समयमा, हामी अवरुद्ध समस्याको वरिपरि काम गर्नेछौं।

Rsyslog ले स्लाइडमा संकेत गरिएका कार्यहरू गर्छ र लगहरू या त रिले वा काफ्कामा पठाउँछ। काफ्का पुरानो बाटो पछ्याउँछन्। रिले - मैले लगहरू डेलिभर गर्न शुद्ध rsyslog प्रयोग गर्ने प्रयास गरें। सन्देश कतार बिना, मानक rsyslog उपकरणहरू प्रयोग गरेर। मूलतः, यसले काम गर्दछ।

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

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

समस्याहरु के के थिए ? समस्याहरू खडा भयो जब हामीले पत्ता लगायौं (अचानक!) कि हाम्रा लाइभ API हरू प्रति सेकेन्ड 50k सन्देशहरू लेखिरहेका थिए। यो स्टेजिङ बिना मात्र लाइभ API हो। र Graylog ले हामीलाई प्रति सेकेन्ड मात्र 12 हजार सन्देशहरू देखाउँछ। र एक उचित प्रश्न उठ्यो: अवशेषहरू कहाँ छन्? जसबाट हामीले निष्कर्ष निकाल्यौं कि ग्रेलोगले मात्र सामना गर्न सक्दैन। हामीले हेर्यौं, र, वास्तवमा, Graylog र Elasticsearch ले यो प्रवाह ह्यान्डल गर्न सकेन।

अर्को, हामीले बाटोमा गरेका अन्य आविष्कारहरू।

सकेटमा लेख्ने कार्यहरू अवरुद्ध छन्। याे कसरी भयाे? जब मैले डेलिभरीको लागि rsyslog प्रयोग गरिरहेको थिएँ, केहि बिन्दुमा डाटा केन्द्रहरू बीचको च्यानल बिग्रियो। एक ठाउँमा डेलिभरी रोकियो, अर्को ठाउँमा डेलिभरी रोकियो। यो सबै rsyslog सकेटमा लेख्ने API को साथ मेसिनमा पुग्यो। त्यहाँ लाम थियो। त्यसपछि युनिक्स सकेटमा लेख्नको लागि लाम, जुन पूर्वनिर्धारित रूपमा 128 प्याकेट हो, भरियो। र अनुप्रयोगमा अर्को लेख () अवरुद्ध छ। जब हामीले गो एप्लिकेसनहरूमा प्रयोग गर्ने पुस्तकालयमा हेर्यौं, त्यहाँ लेखिएको थियो कि सकेटमा लेख्नु गैर-ब्लकिङ मोडमा हुन्छ। हामी निश्चित थियौं कि केहि पनि रोकिएको छैन। किनभने हामी पढ्छौं Badushechka बारेमा लेखजसले यसको बारेमा लेखे। तर त्यहाँ एक क्षण छ। यस कलको वरिपरि एक अनन्त लूप पनि थियो, जसमा सकेटमा सन्देश पुश गर्ने निरन्तर प्रयास थियो। हामीले उसलाई ध्यान दिएनौं। मैले पुस्तकालयलाई पुनर्लेखन गर्नुपर्‍यो। त्यस पछि यो धेरै पटक परिवर्तन भएको छ, तर अब हामीले सबै उपप्रणालीहरूमा ब्लकिङबाट छुटकारा पाएका छौं। त्यसकारण, तपाइँ rsyslog रोक्न सक्नुहुन्छ, र केहि पनि क्र्यास हुनेछैन।

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

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

इलास्टिक खोज समस्या कसरी समाधान गर्ने? यदि तपाईलाई एकै ठाउँमा द्रुत रूपमा लगहरू प्राप्त गर्न आवश्यक छ, ताकि सबै मेशिनहरू वरिपरि दौडन नपरोस् र तिनीहरूलाई त्यहाँ सङ्कलन गर्नुहोस्, फाइल भण्डारण प्रयोग गर्नुहोस्। यो काम गर्न ग्यारेन्टी छ। यो कुनै पनि सर्भरबाट गर्न सकिन्छ। तपाईंले त्यहाँ डिस्कहरू स्टिक गर्न र syslog स्थापना गर्न आवश्यक छ। यस पछि, तपाइँसँग सबै लगहरू एकै ठाउँमा हुने ग्यारेन्टी छन्। त्यसपछि तपाइँ बिस्तारै elasticsearch, graylog, र केहि अन्य कन्फिगर गर्न सक्नुहुन्छ। तर तपाईंसँग पहिले नै सबै लगहरू हुनेछन्, र यसबाहेक, तपाईंले तिनीहरूलाई भण्डारण गर्न सक्नुहुन्छ जहाँसम्म पर्याप्त डिस्क एरेहरू छन्।

मेरो रिपोर्टको समयमा, योजना यस्तो देखिन थाल्यो। हामीले व्यावहारिक रूपमा फाइलमा लेख्न छोड्यौं। अब, सम्भवतः, हामी बाँकी बन्द गर्नेछौं। API चलाउने स्थानीय मेसिनहरूमा, हामी फाइलहरूमा लेख्न बन्द गर्नेछौं। पहिलो, त्यहाँ फाइल भण्डारण छ, जसले धेरै राम्रो काम गर्दछ। दोस्रो, यी मेशिनहरू लगातार ठाउँबाट दौडिरहेका छन्; यसलाई निरन्तर निगरानी गर्न आवश्यक छ।

Logstash र Graylog को साथ यो भाग, यो वास्तवमै बन्द हुन्छ। त्यसैले यसबाट मुक्ति पाउन जरुरी छ । तपाईंले एउटा कुरा रोज्नुपर्छ।

हामीले Logstash र Kibana बाहिर निकाल्ने निर्णय गर्यौं। किनभने हामीसँग सुरक्षा विभाग छ। कस्तो सम्बन्ध ? जडान भनेको X-Pack बिना र Shield बिना Kibana ले तपाईंलाई लगहरूमा पहुँच अधिकारहरू छुट्याउन अनुमति दिँदैन। त्यसकारण हामीले ग्रेलोग लियौं। यो सबै छ। मलाई यो मन पर्दैन, तर यसले काम गर्छ। हामीले नयाँ हार्डवेयर किन्यौं, त्यहाँ नयाँ ग्रेलोग स्थापना गर्यौं र कडा ढाँचाहरू भएका सबै लगहरूलाई छुट्टै ग्रेलोगमा स्थानान्तरण गर्यौं। हामीले संगठनात्मक रूपमा विभिन्न प्रकारका समान क्षेत्रहरूसँग समस्या समाधान गर्यौं।

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

र फेरि रेक! हामीसँग दुईवटा बिक्री आउँदैछ। हामीले 6 मिलियन सन्देशहरू पार गर्यौं। Graylog सँग चपाउने समय छैन। जसरी पनि हामी फेरि बाँच्नुपर्छ।

यसरी बाँचेका थियौं । हामीले केही थप सर्भर र SSD हरू थप्यौं। अहिले हामी यसरी बाँचिरहेका छौं। अब हामी पहिले नै प्रति सेकेन्ड 160k सन्देशहरू चबाइरहेका छौं। हामीले अझै सीमामा हिर्केका छैनौं, त्यसैले यो स्पष्ट छैन कि हामी वास्तवमा यसबाट कति बाहिर निस्कन सक्छौं।

यी हाम्रा भविष्यका योजनाहरू हुन्। यी मध्ये, सबैभन्दा महत्त्वपूर्ण सम्भवतः उच्च उपलब्धता हो। हामीसँग अझै छैन। धेरै कारहरू एउटै तरिकाले कन्फिगर गरिएका छन्, तर अहिलेसम्म सबै कुरा एउटै कारबाट चलिरहेको छ। तिनीहरू बीच फेलओभर सेट अप गर्न समय लाग्छ।

Graylog बाट मेट्रिक्स सङ्कलन।

दर सीमा बनाउनुहोस् ताकि हामीसँग एउटा पागल API छ जसले हाम्रो ब्यान्डविथ र अरू सबैलाई मार्दैन।

र अन्तमा, विकासकर्ताहरूसँग केहि प्रकारको SLA मा हस्ताक्षर गर्नुहोस् ताकि हामी यो धेरै सेवा गर्न सक्छौं। थप लेख्नु भयो भने माफी चाहन्छु ।

र कागजात लेख्नुहोस्।

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

तपाईंका प्रश्नहरू.

तपाईंको प्रश्न: तपाईंले किन नलिने निर्णय गर्नुभयो... (फाइलबिट?)

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

तपाईंको प्रश्न: तपाईं किन HDFS मा लगहरू मात्र लेख्नुहुन्न?

जवाफ दिनुहोस्: यो अर्को चरण हो। हामीले यसको बारेमा सुरुमै सोच्यौं, तर अहिले यो गर्नका लागि कुनै स्रोतहरू छैनन्, यो हाम्रो दीर्घकालीन समाधानमा टाँसिएको छ।

तपाईंको प्रश्न: स्तम्भ ढाँचा अधिक उपयुक्त हुनेछ।

जवाफ दिनुहोस्: म बुझ्दछु। हामी दुबै हातले यसको लागि छौं।

तपाईंको प्रश्न: तपाईं rsyslog मा लेख्दै हुनुहुन्छ। त्यहाँ तपाइँ TCP र UDP दुवै प्रयोग गर्न सक्नुहुन्छ। तर यदि UDP, तब तपाइँ कसरी डेलिभरीको ग्यारेन्टी गर्नुहुन्छ?

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

तपाईंको प्रश्न: जब API ले लगमा केही सन्देश उत्पन्न गर्छ र microservices मा नियन्त्रण स्थानान्तरण गर्छ, के तपाईंले विभिन्न माइक्रोसर्भिसेसहरूबाट सन्देशहरू गलत क्रममा आउने समस्याको सामना गर्नुभएको छ? यसले अन्योल निम्त्याउँछ।

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

तपाईंको प्रश्न: टाइमस्ट्याम्प मिलिसेकेन्डमा फरक हुन सक्छ।

जवाफ दिनुहोस्: टाइमस्ट्याम्प एपीआई आफैले उत्पन्न गरेको हो। यो, वास्तवमा, सम्पूर्ण बिन्दु हो। हामीसँग NTP छ। API ले सन्देशमा नै टाइमस्ट्याम्प उत्पन्न गर्छ। rsyslog ले थप गर्दैन।

तपाईंको प्रश्न: डाटा केन्द्रहरू बीचको अन्तरक्रिया धेरै स्पष्ट छैन। डाटा सेन्टर भित्र, लगहरू कसरी सङ्कलन र प्रशोधन गरियो भन्ने स्पष्ट छ। डाटा केन्द्रहरू बीचको अन्तरक्रिया कसरी हुन्छ? वा प्रत्येक डाटा केन्द्रले आफ्नै जीवन बिताउँछ?

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

तपाईंको प्रश्न: असामान्य परिस्थितिको अवस्थामा, के तपाइँ त्यहाँबाट लगहरू प्राप्त गर्नुहुन्छ?

जवाफ दिनुहोस्: तपाईं त्यहाँ जान सक्नुहुन्छ (फाइल भण्डारणमा) र हेर्न सक्नुहुन्छ।

तपाईंको प्रश्न: तपाईंले लगहरू हराउनुभएको छैन भनेर कसरी निगरानी गर्नुहुन्छ?

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

तपाईंको प्रश्न: elasticsearch मा तपाईले लगहरू रिडन्डन्सीको साथ भण्डार गर्नुहुन्छ। तपाईंसँग कतिवटा प्रतिकृतिहरू छन्?

जवाफ दिनुहोस्: एक लाइन।

तपाईंको प्रश्न: के यो एउटा लाइन मात्र हो?

जवाफ दिनुहोस्: यो गुरु र प्रतिकृति हो। डाटा दुई प्रतिलिपिहरूमा भण्डारण गरिएको छ।

तपाईंको प्रश्न: के तपाईंले rsyslog बफर साइज कुनै न कुनै रूपमा समायोजन गर्नुभयो?

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

प्रश्न: के तपाई टुटेको JSON लेख्नुहुन्छ?

जवाफ दिनुहोस्: भाँचिएको JSON या त रिलेको समयमा खारेज गरिनेछ किनभने प्याकेट धेरै ठूलो छ। वा Graylog खारेज गरिनेछ किनभने यसले JSON पार्स गर्न सक्दैन। तर त्यहाँ नक्साहरू छन् जुन निश्चित गर्न आवश्यक छ, र तिनीहरू प्रायः rsyslog मा बाँधिएका छन्। मैले त्यहाँ धेरै मुद्दाहरू भरेको छु, जसमा अझै काम गर्न आवश्यक छ।

प्रश्न: किन काफ्का ? के तपाईंले RabbitMQ प्रयास गर्नुभयो? के ग्रेलोग यस्तो भार अन्तर्गत असफल हुन्छ?

जवाफ दिनुहोस्: यो Graylog को साथ हाम्रो लागि काम गरिरहेको छैन। र Graylog हाम्रो लागि आकार लिइरहेको छ। उहाँ साँच्चै समस्याग्रस्त हुनुहुन्छ। उ एउटा बेग्लै कुरा हो। र, वास्तवमा, यो आवश्यक छैन। म rsyslog बाट सिधै elasticsearch मा लेख्न रुचाउँछु र त्यसपछि Kibana मा हेर्न चाहन्छु। तर हामीले सुरक्षा गार्डहरूसँग समस्या समाधान गर्न आवश्यक छ। यो हाम्रो विकासको लागि एक सम्भावित विकल्प हो, जब हामी Graylog बाहिर फ्याँक्छौं र Kibana प्रयोग गर्छौं। Logstash प्रयोग गर्नुको कुनै मतलब छैन। किनकि म rsyslog को साथ एउटै कुरा गर्न सक्छु। र यो elasticsearch मा लेख्न को लागी एक मोड्युल छ। हामी Graylog सँग कुनै न कुनै रूपमा बाँच्ने प्रयास गर्दैछौं। हामीले यसलाई अलिकति ट्युन पनि गर्यौं। तर सुधारको लागि अझै ठाउँ छ।

Kafka को बारेमा ऐतिहासिक रूपमा यो यसरी भएको छ। जब म आइपुगे, यो पहिले नै त्यहाँ थियो, र लग पहिले नै यसमा लेखिएको थियो। हामीले केवल हाम्रो क्लस्टर उठायौं र यसमा लगहरू सारियो। हामी उहाँको व्यवस्थापन हौं, हामीलाई थाहा छ उहाँ कस्तो महसुस गर्नुहुन्छ। RabbitMQ को लागि... यसले RabbitMQ सँग हाम्रो लागि काम गर्दैन। र RabbitMQ हाम्रो लागि आकार लिइरहेको छ। हामीसँग उत्पादनमा छ, र यसमा समस्याहरू थिए। अब, बिक्री अघि, तिनीहरूले उसलाई आकर्षण गर्नेछन्, र उसले सामान्य रूपमा काम गर्न थाल्छ। तर त्यसअघि म यसलाई उत्पादनमा ल्याउन तयार थिइनँ । त्यहाँ अर्को बिन्दु छ। Graylog ले संस्करण AMQP 0.9 पढ्न सक्छ, र rsyslog ले संस्करण AMQP 1.0 लेख्न सक्छ। र बीचमा एक मात्र समाधान छैन जुन दुबै गर्न सक्छ। यो एक वा अर्को हो। त्यसैले अहिले काफ्का मात्रै हुन् । तर यसको पनि आफ्नै नक्साहरू छन्। किनभने हामीले प्रयोग गर्ने rsyslog को संस्करणको omkafka ले rsyslog बाट बाहिर निकालेको सम्पूर्ण सन्देश बफर गुमाउन सक्छ। अहिलेको लागि हामीले त्यसलाई सह्यौं।

प्रश्नके तपाईं काफ्का प्रयोग गर्नुहुन्छ किनभने तपाईंसँग पहिले नै थियो? अब कुनै उद्देश्यको लागि प्रयोग नगर्ने?

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

प्रश्न: किन हामीलाई सकेटहरूसँग यो शमनवाद चाहिन्छ? के तपाईंले कन्टेनरहरूको लागि syslog लग ड्राइभर प्रयोग गर्ने प्रयास गर्नुभएको छ?

जवाफ दिनुहोस्: हामीले यो प्रश्न सोध्दा डकरसँगको हाम्रो सम्बन्ध तनावपूर्ण थियो। यो डकर १.० वा ०.९ थियो। डकर आफैमा अनौठो थियो। दोस्रो, यदि तपाइँ यसमा लगहरू पनि पुश गर्नुहुन्छ भने... मसँग एक अप्रमाणित शंका छ कि यसले सबै लगहरू आफै मार्फत, डकर डेमन मार्फत पार गर्दछ। यदि एउटा एपीआई पागल हुन्छ भने, बाँकी एपीआईहरू stdout र stderr पठाउन नसक्ने तथ्यमा अड्किएका छन्। मलाई थाहा छैन यसले कहाँ पुर्‍याउँछ। मलाई यो ठाउँमा डकर syslog ड्राइभर प्रयोग गर्न आवश्यक छैन भन्ने भावनाको स्तरमा शंका छ। हाम्रो कार्यात्मक परीक्षण विभागसँग लगहरूसँग आफ्नै ग्रेलोग क्लस्टर छ। तिनीहरूले डकर लग ड्राइभरहरू प्रयोग गर्छन् र त्यहाँ सबै कुरा ठीक देखिन्छ। तर तिनीहरूले तुरुन्तै ग्रेलोगमा GELF लेख्छन्। हामीले यो सबै थालेको समयमा, हामीलाई यो काम गर्न आवश्यक थियो। सायद पछि, कसैले आएर सय वर्षदेखि राम्रो काम गरिरहेको छ भने, हामी प्रयास गर्नेछौं।

प्रश्न: तपाईं rsyslog प्रयोग गरेर डाटा केन्द्रहरू बीच डेलिभरी गर्नुहुन्छ। काफ्का किन होइन?

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

स्रोत: www.habr.com