युरी बुशमेलेव्ह "लॉग गोळा आणि वितरित करण्याच्या फील्डवरील रेकचा नकाशा" - अहवालाचा उतारा

लॉग हे सिस्टीमचा एक महत्त्वाचा भाग आहे, ज्यामुळे ते अपेक्षेप्रमाणे कार्य करत आहे (किंवा काम करत नाही) हे समजू देते. मायक्रोसर्व्हिस आर्किटेक्चरमध्ये, लॉगसह काम करणे ही विशेष ऑलिम्पियाडसाठी एक वेगळी शिस्त बनते. प्रश्नांचा एक समूह एकाच वेळी सोडवणे आवश्यक आहे:

• अनुप्रयोगावरून लॉग कसे लिहायचे;
• नोंदी कुठे लिहायच्या;
• स्टोरेज आणि प्रक्रियेसाठी लॉग कसे वितरित करावे;
• नोंदींवर प्रक्रिया आणि संचयन कसे करावे.

सध्या लोकप्रिय कंटेनरायझेशन तंत्रज्ञानाचा वापर समस्या सोडवण्याच्या पर्यायांच्या क्षेत्रात रेकच्या शीर्षस्थानी वाळू जोडतो.

युरी बुशमेलेव्हच्या अहवालाचा उतारा "लग गोळा करणे आणि वितरीत करण्याच्या क्षेत्रात रेकचा नकाशा" याविषयी आहे.

कोण काळजी घेते, कृपया मांजरीच्या खाली.

माझे नाव युरी बुशमेलेव्ह आहे. मी लाझाडा येथे काम करतो. आज आम्ही आमचे लॉग कसे बनवले, आम्ही ते कसे गोळा केले आणि आम्ही तेथे काय लिहितो याबद्दल बोलेन.

आम्ही कुठून आहोत? आम्ही कोण आहोत? Lazada आग्नेय आशियातील सहा देशांमध्ये नंबर 1 ऑनलाइन रिटेलर आहे. हे सर्व देश आमच्या डेटा सेंटरमध्ये वितरीत केले जातात. सध्या एकूण 4 डेटा सेंटर आहेत. हे महत्त्वाचे का आहे? कारण काही निर्णय केंद्रांमध्ये अत्यंत कमकुवत दुवा असल्यामुळे होते. आमच्याकडे मायक्रोसर्व्हिस आर्किटेक्चर आहे. आमच्याकडे आधीच 80 मायक्रो सर्व्हिसेस आहेत हे पाहून मला आश्चर्य वाटले. जेव्हा मी लॉगसह कार्य सुरू केले, तेव्हा त्यापैकी फक्त 20 होते. शिवाय PHP वारशाचा एक मोठा तुकडा आहे, ज्याला मला जगावे लागेल आणि ते सहन करावे लागेल. हे सर्व सध्या संपूर्ण प्रणालीसाठी प्रति मिनिट 6 दशलक्ष संदेश व्युत्पन्न करते. पुढे मी दाखवेन की आपण यासह कसे जगण्याचा प्रयत्न करीत आहोत आणि हे असे का आहे.

तुम्हाला या 6 दशलक्ष संदेशांसह कसे तरी जगावे लागेल. त्यांच्याशी आपण काय करावे? तुम्हाला आवश्यक असलेले 6 दशलक्ष संदेश:

• अॅपवरून पाठवा
• वितरणासाठी स्वीकारा
• विश्लेषण आणि स्टोरेजसाठी वितरित करा.
• विश्लेषण करा
• ते कसे तरी साठवा.

जेव्हा तीन दशलक्ष संदेश दिसले, तेव्हा मी तेच पाहिले. कारण आम्ही फक्त काही पैशांनी सुरुवात केली. हे स्पष्ट आहे की अर्ज नोंदी तेथे लिहिले आहेत. उदाहरणार्थ, मी डेटाबेसशी कनेक्ट होऊ शकलो नाही, मी डेटाबेसशी कनेक्ट करू शकलो पण मी काहीही वाचू शकलो नाही. परंतु याशिवाय, आमची प्रत्येक मायक्रोसर्व्हिसेस ऍक्सेस लॉग देखील लिहिते. मायक्रोसर्व्हिसवर येणारी प्रत्येक विनंती लॉगमध्ये रेकॉर्ड केली जाते. आपण हे का करत आहोत? विकसकांना ट्रेस करण्यात सक्षम व्हायचे आहे. प्रत्येक प्रवेश लॉगमध्ये ट्रेसीड फील्ड असते, ज्याचा वापर करून एक विशेष इंटरफेस नंतर संपूर्ण साखळी उघडतो आणि ट्रेस सुंदरपणे प्रदर्शित करतो. विनंती कशी झाली हे ट्रेस दर्शविते आणि हे आमच्या विकासकांना कोणत्याही अज्ञात कचऱ्याचा त्वरित सामना करण्यास मदत करते.

यासह कसे जगायचे? आता मी पर्यायांच्या फील्डचे थोडक्यात वर्णन करेन - ही समस्या सामान्यतः कशी सोडवली जाते. लॉग गोळा करणे, प्रसारित करणे आणि संग्रहित करणे या समस्येचे निराकरण कसे करावे.

अर्जावरून कसे लिहायचे? हे स्पष्ट आहे की विविध मार्ग आहेत. विशेषतः, सर्वोत्तम सराव आहे, जसे आमचे फॅशनेबल कॉमरेड आम्हाला सांगतात. आमच्या आजोबांनी सांगितल्याप्रमाणे जुन्या शाळेचे दोन प्रकार आहेत. इतर मार्ग आहेत.

नोंदी गोळा करण्याची परिस्थिती अंदाजे समान आहे. या विशिष्ट भागाचे निराकरण करण्यासाठी बरेच पर्याय नाहीत. त्यापैकी बरेच आधीच आहेत, परंतु अद्याप इतके नाहीत.

परंतु वितरण आणि त्यानंतरच्या विश्लेषणासह, भिन्नतेची संख्या विस्फोट होऊ लागते. मी आता प्रत्येक पर्यायाचे वर्णन करणार नाही. मला वाटते की मुख्य पर्याय या विषयात स्वारस्य असलेल्या प्रत्येकासाठी सुप्रसिद्ध आहेत.

लाझाडा येथे आम्ही ते कसे केले आणि हे सर्व प्रत्यक्षात कसे सुरू झाले ते मी तुम्हाला दाखवतो.

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

आता थोडे पुढे पाहू. आम्ही हे लॉग कसे वितरित केले? कोणीतरी td-एजंट निवडला, जो प्रत्यक्षात अस्खलित आहे, परंतु फारसा प्रवाही नाही. मला अजूनही या दोन प्रकल्पांमधील संबंध समजले नाहीत, परंतु ते एकाच गोष्टीबद्दल आहेत असे दिसते. आणि हे अस्खलित, रुबीमध्ये लिहिलेले, लॉग फाइल्स वाचले, काही प्रकारची नियमितता वापरून त्यांना JSON मध्ये पार्स केले. मग मी त्यांना काफ्काकडे पाठवले. शिवाय, काफ्कामध्ये आमच्याकडे प्रत्येक API साठी 4 स्वतंत्र विषय होते. 4 का? कारण लाइव्ह आहे, स्टेजिंग आहे, आणि कारण stdout आणि stderr आहे. विकासक ते तयार करतात आणि पायाभूत सुविधा विकसकांनी ते काफ्कामध्ये तयार केले पाहिजेत. शिवाय, काफ्का दुसर्या विभागाद्वारे नियंत्रित होते. म्हणून, एक तिकीट तयार करणे आवश्यक होते जेणेकरून ते प्रत्येक एपीआयसाठी 4 विषय तयार करतील. सर्वजण ते विसरले. सर्वसाधारणपणे, कचरा आणि गडबड होते.

याचं पुढे आम्ही काय केलं? आम्ही ते काफ्काकडे पाठवले. मग काफ्काचे निम्मे लॉग लॉगस्टॅशला गेले. लॉगचे बाकीचे अर्धे भाग विभागले गेले. काही एका ग्रेलॉगकडे, काहींनी दुसऱ्या ग्रेलॉगकडे उड्डाण केले. परिणामी, हे सर्व एका Elasticsearch क्लस्टरमध्ये गेले. म्हणजेच हा सगळा गोंधळ तिथेच संपला. असे करू नका!

वरून बघितले तर हेच दिसते. असे करू नका! येथे समस्या क्षेत्र ताबडतोब अंकांसह चिन्हांकित केले जातात. प्रत्यक्षात त्यापैकी बरेच आहेत, परंतु 6 खरोखरच समस्याप्रधान आहेत ज्याबद्दल काहीतरी करणे आवश्यक आहे. मी आता त्यांच्याबद्दल स्वतंत्रपणे सांगेन.

येथे (1,2,3) आपण फायली लिहितो आणि त्यानुसार, येथे एकाच वेळी तीन रेक आहेत.

पहिली (1) ती कुठेतरी लिहायची आहे. API ला थेट फाइलवर लिहिण्याची क्षमता देणे नेहमीच इष्ट नसते. एपीआय कंटेनरमध्ये वेगळे करणे इष्ट आहे, किंवा त्याहूनही चांगले, ते केवळ वाचनीय असावे. मी एक प्रणाली प्रशासक आहे, त्यामुळे या गोष्टींकडे माझा थोडासा पर्यायी दृष्टिकोन आहे.

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

(4) आमच्याकडे वेगवेगळ्या API मध्ये भिन्न स्वरूप होते. ते थोडे वेगळे होते, परंतु regexp वेगळ्या पद्धतीने लिहावे लागले. हे सर्व पपेटद्वारे नियंत्रित केले जात असल्याने, त्यांच्या स्वत: च्या झुरळांसह वर्गांचा मोठा जमाव होता. शिवाय, बहुतेक वेळा टीडी-एजंट मेमरी खाऊ शकतो, मूर्ख असू शकतो, तो फक्त काम करत असल्याचे भासवू शकतो आणि काहीही करू शकत नाही. बाहेरून हे समजणे अशक्य होते की तो काहीही करत नाही. सर्वोत्तम, तो पडेल आणि नंतर कोणीतरी त्याला उचलेल. अधिक तंतोतंत, एक इशारा येईल, आणि कोणीतरी जाईल आणि त्यांच्या हातांनी ते वाढवेल.

(6) आणि सर्वात कचरा आणि कचरा म्हणजे लवचिक शोध. कारण ती जुनी आवृत्ती होती. कारण त्यावेळी आमच्याकडे समर्पित मास्टर्स नव्हते. आमच्याकडे विषम लॉग होते ज्यांचे फील्ड ओव्हरलॅप होऊ शकतात. वेगवेगळ्या ऍप्लिकेशन्समधील वेगवेगळे लॉग समान फील्डच्या नावांनी लिहिले जाऊ शकतात, परंतु आत भिन्न डेटा असू शकतो. म्हणजेच, फील्डमध्ये पूर्णांकासह एक लॉग येतो, उदाहरणार्थ, स्तर. दुसरा लॉग लेव्हल फील्डमध्ये स्ट्रिंगसह येतो. स्थिर मॅपिंगच्या अनुपस्थितीत, ही एक आश्चर्यकारक गोष्ट आहे. जर, इलास्टिकसर्चमध्ये निर्देशांक फिरवल्यानंतर, स्ट्रिंगसह संदेश प्रथम आला, तर आपण सामान्यपणे जगू. परंतु जर पहिला पूर्णांक वरून आला असेल, तर त्यानंतरचे सर्व संदेश जे स्ट्रिंगवरून आले आहेत ते फक्त टाकून दिले जातात. कारण फील्ड प्रकार जुळत नाही.

असे प्रश्न आम्ही विचारू लागलो. ज्यांना दोष द्यावा लागेल ते शोधायचे नाही असे आम्ही ठरवले.

पण काहीतरी केले पाहिजे! स्पष्ट गोष्ट अशी आहे की आपल्याला मानके स्थापित करणे आवश्यक आहे. आमच्याकडे आधीच काही मानके होती. आम्ही थोड्या वेळाने सुरुवात केली. सुदैवाने, त्या वेळी सर्व API साठी एकल लॉग स्वरूप आधीच मंजूर केले गेले होते. सेवांमधील परस्परसंवादासाठी ते थेट मानकांमध्ये लिहिलेले आहे. त्यानुसार, ज्यांना नोंदी घ्यायच्या आहेत त्यांनी ते या फॉरमॅटमध्ये लिहावेत. जर कोणी या फॉरमॅटमध्ये लॉग लिहित नसेल तर आम्ही कशाचीही हमी देत ​​नाही.

पुढे, मी रेकॉर्डिंग, वितरण आणि लॉग गोळा करण्याच्या पद्धतींसाठी एक एकीकृत मानक तयार करू इच्छितो. वास्तविक, ते कुठे लिहायचे आणि ते कसे वितरित करायचे. जेव्हा प्रकल्प समान लायब्ररी वापरतात तेव्हा आदर्श परिस्थिती असते. Go साठी वेगळी लॉगिंग लायब्ररी आणि PHP साठी वेगळी लायब्ररी आहे. आमच्याकडे असलेल्या प्रत्येकाने त्यांचा वापर केला पाहिजे. या क्षणी, मी म्हणेन की आम्ही यात 80 टक्के यशस्वी आहोत. पण काही लोक कॅक्टी खात राहतात.

आणि तिथे (स्लाइडवर) “लॉग डिलिव्हरीसाठी SLA” क्वचितच दिसू लागते. ते अद्याप अस्तित्वात नाही, परंतु आम्ही त्यावर काम करत आहोत. कारण जेव्हा इन्फ्रास्ट्रक्चर म्हणते की जर तुम्ही अशा आणि अशा ठिकाणी अशा फॉरमॅटमध्ये लिहिल्यास आणि प्रति सेकंद N संदेशांपेक्षा जास्त नसेल, तर आम्ही बहुधा ते अशा ठिकाणी पोहोचवू. यामुळे डोकेदुखीपासून खूप आराम मिळतो. SLA असल्यास, हे अगदी आश्चर्यकारक आहे!

आम्ही समस्येचे निराकरण कसे सुरू केले? मुख्य समस्या टीडी-एजंटची होती. आमच्या नोंदी कुठे गेल्या हे कळत नव्हते. ते वितरित केले जातात? ते जात आहेत का? तरीही ते कुठे आहेत? म्हणून, पहिला मुद्दा टीडी-एजंट बदलण्याचा निर्णय घेण्यात आला. ते काय बदलायचे याचे पर्याय मी येथे थोडक्यात दिले आहेत.

अस्खलित. प्रथम, मी त्याला मागील नोकरीवर भेटलो आणि तो अधूनमधून तेथे पडला. दुसरे म्हणजे, ही समान गोष्ट आहे, केवळ प्रोफाइलमध्ये.

फाइलबीट. आमच्यासाठी ते कसे सोयीचे होते? कारण ते Go मध्ये आहे आणि आमच्याकडे Go मध्ये बरेच कौशल्य आहे. त्यानुसार, जर काही घडले तर, आम्ही स्वतःसाठी त्यात कशीतरी भर घालू शकतो. म्हणूनच आम्ही ते घेतले नाही. जेणेकरून स्वतःसाठी ते पुन्हा लिहिण्याचा मोहही पडू नये.

सिस्टीम ऍडमिनिस्ट्रेटरसाठी स्पष्ट उपाय म्हणजे या प्रमाणात सर्व प्रकारचे syslogs (syslog-ng/rsyslog/nxlog).

किंवा तुमचे स्वतःचे काहीतरी लिहा, परंतु आम्ही हे तसेच फाइलबीट टाकून दिले. तुम्ही काही लिहिल्यास, व्यवसायासाठी उपयुक्त असे काहीतरी लिहिणे चांगले. नोंदी वितरीत करण्यासाठी, तयार काहीतरी घेणे चांगले आहे.

म्हणून, निवड प्रत्यक्षात syslog-ng आणि rsyslog मधील निवडीवर आली. मी rsyslog कडे झुकलो कारण आमच्याकडे पपेट मध्ये rsyslog चे वर्ग आधीच आहेत आणि मला त्यांच्यात स्पष्ट फरक दिसला नाही. syslog काय आहे, syslog काय आहे. होय, काहींचे दस्तऐवज खराब आहेत, काही चांगले आहेत. हा एक अशा प्रकारे करू शकतो आणि दुसरा ते वेगळ्या प्रकारे करू शकतो.

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

rsyslog चे इतर अनेक तोटे आहेत. ते बोनस सारखेच आहेत. मुख्य समस्या अशी आहेत की आपल्याला ते कसे शिजवायचे हे माहित असणे आवश्यक आहे आणि आपल्याला आवृत्ती निवडण्याची आवश्यकता आहे.

आम्ही ठरवले की आम्ही युनिक्स सॉकेटवर लॉग लिहू. आणि /dev/log मध्ये नाही, कारण तिथे आमच्याकडे सिस्टम लॉगचा गोंधळ आहे, जर्नल्ड या पाइपलाइनमध्ये आहे. तर सानुकूल सॉकेटवर लिहूया. आम्ही ते एका वेगळ्या नियमावलीशी संलग्न करू. चला कोणत्याही गोष्टीत हस्तक्षेप करू नका. सर्व काही पारदर्शक आणि समजण्यायोग्य असेल. आम्ही नेमके तेच केले. या सॉकेट्स असलेली निर्देशिका प्रमाणित केली जाते आणि सर्व कंटेनरवर अग्रेषित केली जाते. कंटेनर त्यांना आवश्यक असलेले सॉकेट पाहू शकतात, उघडू शकतात आणि त्यावर लिहू शकतात.

फाईल का नाही? कारण सर्वांनी ते वाचले आहे Badushechka बद्दल लेख, ज्याने डॉकरकडे फाइल अग्रेषित करण्याचा प्रयत्न केला, आणि असे आढळून आले की rsyslog रीस्टार्ट केल्यानंतर, फाइल वर्णनकर्ता बदलला आणि डॉकरने ही फाइल गमावली. हे दुसरे काहीतरी उघडे ठेवते, परंतु ते जिथे लिहित आहेत ते सॉकेट नाही. आम्ही ठरवले की आम्ही या समस्येवर काम करू आणि त्याच वेळी, आम्ही ब्लॉकिंग समस्येवर काम करू.

Rsyslog स्लाइडवर सूचित केलेल्या क्रिया करतो आणि रिले किंवा काफ्काला लॉग पाठवतो. काफ्का जुन्या मार्गाचा अवलंब करतो. रिले - मी लॉग वितरित करण्यासाठी शुद्ध rsyslog वापरण्याचा प्रयत्न केला. संदेश रांगेशिवाय, मानक rsyslog साधने वापरून. मूलतः, ते कार्य करते.

परंतु त्यांना या भागामध्ये कसे ढकलायचे याच्या बारकावे आहेत (लॉगस्टॅश/ग्रेलॉग/ईएस). हा भाग (rsyslog-rsyslog) डेटा केंद्रांमध्ये वापरला जातो. येथे एक संकुचित tcp लिंक आहे, जी आम्हाला बँडविड्थ जतन करण्यास अनुमती देते आणि त्यानुसार, चॅनेल बंद झाल्यावर आम्हाला दुसर्‍या डेटा सेंटरमधून काही लॉग मिळण्याची शक्यता वाढते. कारण आपल्याकडे इंडोनेशिया आहे, जिथे सर्व काही वाईट आहे. येथेच सतत समस्या असते.

आम्ही विचार केला की आम्ही अनुप्रयोगातून रेकॉर्ड केलेले लॉग शेवटपर्यंत पोहोचण्याची किती शक्यता आहे याचे निरीक्षण कसे करता येईल? आम्ही मेट्रिक्स तयार करण्याचा निर्णय घेतला. rsyslog चे स्वतःचे स्टॅटिस्टिक्स कलेक्शन मॉड्यूल आहे, ज्यामध्ये काही प्रकारचे काउंटर आहेत. उदाहरणार्थ, ते तुम्हाला रांगेचा आकार किंवा अशा आणि अशा कृतीमध्ये किती संदेश आले आहेत हे दाखवू शकतात. आपण आधीच त्यांच्याकडून काहीतरी घेऊ शकता. तसेच, त्यात सानुकूल काउंटर आहेत जे कॉन्फिगर केले जाऊ शकतात आणि ते तुम्हाला दर्शवेल, उदाहरणार्थ, काही API रेकॉर्ड केलेल्या संदेशांची संख्या. पुढे, मी पायथनमध्ये rsyslog_exporter लिहिले आणि आम्ही ते सर्व प्रोमिथियसला पाठवले आणि आलेख तयार केले. आम्हाला खरोखर ग्रेलॉग मेट्रिक्स हवे होते, परंतु ते सेट करण्यासाठी आमच्याकडे अद्याप वेळ नाही.

काय समस्या होत्या? आमचे Live API प्रति सेकंद 50k संदेश लिहित असल्याचे आम्हाला (अचानक!) आढळले तेव्हा समस्या उद्भवल्या. हे स्टेजिंगशिवाय फक्त एक थेट API आहे. आणि ग्रेलॉग आम्हाला प्रति सेकंद फक्त 12 हजार संदेश दाखवतो. आणि एक वाजवी प्रश्न उद्भवला: अवशेष कोठे आहेत? ज्यावरून आम्ही असा निष्कर्ष काढला की ग्रेलॉग फक्त सामना करू शकत नाही. आम्ही पाहिले, आणि खरंच, ग्रेलॉग आणि इलास्टिकसर्च हा प्रवाह हाताळू शकले नाहीत.

पुढे, आम्ही वाटेत इतर शोध लावले.

सॉकेटवर लिहिणे अवरोधित केले आहे. हे कसे घडले? जेव्हा मी वितरणासाठी rsyslog वापरत होतो, तेव्हा काही क्षणी डेटा केंद्रांमधील चॅनेल तुटले. एका ठिकाणी डिलिव्हरी थांबली, दुसऱ्या ठिकाणी डिलिव्हरी थांबली. हे सर्व API सह मशीनवर पोहोचले आहे जे rsyslog सॉकेटवर लिहितात. तिथे रांग लागली होती. नंतर युनिक्स सॉकेटवर लिहिण्यासाठी रांग, जी डीफॉल्टनुसार 128 पॅकेट्स असते, भरली जाते. आणि ऍप्लिकेशनमधील पुढील लेखन () ब्लॉक केले आहे. जेव्हा आम्ही गो ऍप्लिकेशन्समध्ये वापरत असलेल्या लायब्ररीकडे पाहिले तेव्हा तेथे असे लिहिले होते की सॉकेटवर लेखन नॉन-ब्लॉकिंग मोडमध्ये होते. आम्हाला खात्री होती की काहीही ब्लॉक केलेले नाही. कारण आपण वाचतो Badushechka बद्दल लेखज्याने याबद्दल लिहिले. पण एक क्षण आहे. या कॉलभोवती एक अनंत पळवाट देखील होती, ज्यामध्ये सॉकेटमध्ये संदेश ढकलण्याचा सतत प्रयत्न केला जात असे. आम्ही त्याच्याकडे लक्ष दिले नाही. मला लायब्ररी पुन्हा लिहायची होती. तेव्हापासून ते अनेक वेळा बदलले आहे, परंतु आता आम्ही सर्व उपप्रणालींमध्ये ब्लॉकिंगपासून मुक्त झालो आहोत. म्हणून, तुम्ही rsyslog थांबवू शकता, आणि काहीही क्रॅश होणार नाही.

रांगांच्या आकाराचे निरीक्षण करणे आवश्यक आहे, जे या दंताळेवर पाऊल ठेवण्यास टाळण्यास मदत करते. प्रथम, जेव्हा आम्ही संदेश गमावू लागतो तेव्हा आम्ही निरीक्षण करू शकतो. दुसरे म्हणजे, आम्ही प्रसूतीमध्ये समस्या असल्याचे निरीक्षण करू शकतो.

आणि आणखी एक अप्रिय क्षण - मायक्रोसर्व्हिस आर्किटेक्चरमध्ये 10 पट वाढवणे खूप सोपे आहे. आमच्याकडे येणार्‍या अनेक विनंत्या नाहीत, परंतु हे संदेश ज्या ग्राफसह पुढे जातात, प्रवेश नोंदींमुळे, आम्ही लॉग लोड जवळजवळ दहापट वाढवतो. दुर्दैवाने, माझ्याकडे अचूक संख्या मोजण्यासाठी वेळ नव्हता, परंतु मायक्रोसर्व्हिसेस तेच आहेत. हे लक्षात ठेवले पाहिजे. हे निष्पन्न झाले की या क्षणी लॉग कलेक्शन सबसिस्टम लाझाडामध्ये सर्वात जास्त लोड आहे.

लवचिक शोध समस्या कशी सोडवायची? तुम्हाला एकाच ठिकाणी लॉग पटकन मिळवायचे असतील, जेणेकरून सर्व मशिन्सकडे धावून ती तेथे गोळा करू नयेत, फाइल स्टोरेज वापरा. हे काम करण्याची हमी आहे. हे कोणत्याही सर्व्हरवरून केले जाऊ शकते. तुम्हाला फक्त तिथे डिस्क चिकटवून syslog स्थापित करणे आवश्यक आहे. यानंतर, तुमच्याकडे सर्व लॉग एकाच ठिकाणी असण्याची हमी दिली जाते. मग तुम्ही हळूहळू elasticsearch, graylog आणि काहीतरी कॉन्फिगर करू शकता. परंतु तुमच्याकडे आधीपासूनच सर्व नोंदी असतील, आणि त्याशिवाय, पुरेशी डिस्क अॅरे आहेत तोपर्यंत तुम्ही ते संग्रहित करू शकता.

माझ्या अहवालाच्या वेळी ही योजना अशी दिसू लागली. आम्ही व्यावहारिकरित्या फाइलवर लिहिणे बंद केले. आता, बहुधा, आम्ही उर्वरित बंद करू. API चालवणार्‍या स्थानिक मशीनवर, आम्ही फायली लिहिणे थांबवू. प्रथम, फाइल स्टोरेज आहे, जे खूप चांगले कार्य करते. दुसरे म्हणजे, या मशीन्सची सतत जागा संपत आहे; त्यावर सतत लक्ष ठेवणे आवश्यक आहे.

Logstash आणि Graylog सह हा भाग, तो खरोखर बंद करतो. म्हणून, आपण यापासून मुक्त होणे आवश्यक आहे. तुम्हाला एक गोष्ट निवडावी लागेल.

आम्ही लॉगस्टॅश आणि किबाना बाहेर टाकण्याचा निर्णय घेतला. कारण आमच्याकडे सुरक्षा विभाग आहे. काय कनेक्शन? कनेक्शन असे आहे की X-Pack शिवाय आणि Shield शिवाय Kibana तुम्हाला लॉगच्या प्रवेश अधिकारांमध्ये फरक करण्याची परवानगी देत ​​​​नाही. म्हणूनच आम्ही ग्रेलॉग घेतला. त्यात हे सर्व आहे. मला ते आवडत नाही, परंतु ते कार्य करते. आम्ही नवीन हार्डवेअर विकत घेतले, तेथे नवीन ग्रेलॉग स्थापित केले आणि कठोर स्वरूप असलेले सर्व लॉग वेगळ्या ग्रेलॉगमध्ये हस्तांतरित केले. आम्ही वेगवेगळ्या प्रकारच्या समान फील्डसह संघटनात्मकदृष्ट्या समस्या सोडवली.

नवीन ग्रेलॉगमध्ये नेमके काय समाविष्ट आहे. आम्ही फक्त डॉकरमध्ये सर्वकाही लिहिले. आम्ही सर्व्हरचा एक समूह घेतला, तीन काफ्का उदाहरणे आणली, 7 ग्रेलॉग सर्व्हर आवृत्ती 2.3 (कारण आम्हाला इलास्टिकसर्च आवृत्ती 5 हवी होती). एचडीडीकडून छापा टाकताना हे सर्व पकडण्यात आले. आम्ही प्रति सेकंद 100 हजार संदेशांचा अनुक्रमणिका दर पाहिला. आम्ही आकृती पाहिली की दर आठवड्याला 140 टेराबाइट डेटा.

आणि पुन्हा दंताळे! आमच्याकडे दोन विक्री येत आहेत. आम्ही 6 दशलक्ष संदेशांच्या पुढे गेलो. ग्रेलॉगला चघळायला वेळ नाही. कसे तरी पुन्हा जगायचे आहे.

अशा प्रकारे आम्ही वाचलो. आम्ही आणखी काही सर्व्हर आणि SSD जोडले. या क्षणी आपण असे जगतो. आता आम्ही आधीच प्रति सेकंद 160k संदेश चघळत आहोत. आम्ही अद्याप मर्यादा गाठलेली नाही, त्यामुळे आम्ही यातून प्रत्यक्षात किती बाहेर पडू शकतो हे स्पष्ट नाही.

या आमच्या भविष्यासाठीच्या योजना आहेत. यापैकी, सर्वात महत्वाचे म्हणजे उच्च उपलब्धता. आमच्याकडे ते अजून नाही. अनेक कार त्याच प्रकारे कॉन्फिगर केल्या आहेत, परंतु आतापर्यंत सर्व काही एका कारमधून जात आहे. त्यांच्यामध्ये फेलओव्हर सेट करण्यासाठी वेळ लागतो.

Graylog वरून मेट्रिक्स गोळा करा.

दर मर्यादा बनवा जेणेकरुन आमच्याकडे एक वेडा API असेल जो आमची बँडविड्थ आणि इतर सर्व काही नष्ट करत नाही.

आणि शेवटी, विकासकांसोबत काही प्रकारच्या SLA वर स्वाक्षरी करा जेणेकरुन आम्ही इतकी सेवा देऊ शकू. अजून लिहिलं तर माफ करा.

आणि कागदपत्रे लिहा.

थोडक्यात, आम्ही अनुभवलेल्या प्रत्येक गोष्टीचे परिणाम. प्रथम, मानके. दुसरे म्हणजे, सिस्लॉग हा केक आहे. तिसरे म्हणजे, rsyslog हे स्लाईडवर लिहिल्याप्रमाणे कार्य करते. आणि प्रश्नांकडे वळूया.

प्रश्न.

आपला प्रश्न: तुम्ही न घेण्याचा निर्णय का घेतला... (फाइलबीट?)

उत्तर द्या: आपल्याला फाईलवर लिहायचे आहे. मला खरंच करायचं नव्हतं. जेव्हा तुमचा API प्रति सेकंद हजारो संदेश लिहितो, जरी तुम्ही ते तासातून एकदा फिरवले तरीही हा पर्याय नाही. आपण पाईपमध्ये लिहू शकता. ज्यासाठी विकासकांनी मला विचारले: "आम्ही क्रॅश होण्यासाठी लिहित असलेली प्रक्रिया झाल्यास काय होईल?" त्यांना काय उत्तर द्यावे ते मला सापडले नाही आणि म्हणालो: "ठीक आहे, चला ते करू नका."

आपला प्रश्न: तुम्ही फक्त HDFS ला लॉग का लिहीत नाही?

उत्तर द्या: हा पुढचा टप्पा आहे. आम्ही अगदी सुरुवातीस याबद्दल विचार केला होता, परंतु याक्षणी हे करण्यासाठी कोणतेही संसाधने नसल्यामुळे ते आमच्या दीर्घकालीन समाधानामध्ये लटकले आहे.

आपला प्रश्न: स्तंभ स्वरूप अधिक योग्य असेल.

उत्तर द्या: मला समजले. आम्ही दोन्ही हातांनी त्यासाठी आहोत.

आपला प्रश्न: तुम्ही rsyslog वर लिहित आहात. तेथे तुम्ही TCP आणि UDP दोन्ही वापरू शकता. पण जर यूडीपी असेल तर डिलिव्हरीची हमी कशी द्याल?

उत्तर द्या: दोन मुद्दे आहेत. प्रथम, मी सर्वांना लगेच सांगतो की आम्ही लॉग वितरणाची हमी देत ​​नाही. कारण जेव्हा डेव्हलपर येतात आणि म्हणतात: “चला तिथे आर्थिक डेटा लिहायला सुरुवात करा आणि काही घडले तर तुम्ही तो आमच्यासाठी कुठेतरी ठेवू,” आम्ही त्यांना उत्तर देतो, “छान! चला सॉकेटवर लिहिण्यावर ब्लॉक करणे सुरू करूया आणि हे व्यवहारात करूया, जेणेकरुन तुम्ही ते आमच्यासाठी सॉकेटवर ठेवण्याची हमी मिळेल आणि आम्हाला ते दुसऱ्या बाजूने मिळेल याची खात्री करा.” आणि या क्षणी, प्रत्येकाला त्वरित त्याची आवश्यकता नाही. जर ते आवश्यक नसेल तर आपण कोणते प्रश्न विचारावे? जर तुम्हाला सॉकेटवर लिहिण्याची हमी द्यायची नसेल, तर आम्हाला डिलिव्हरीची हमी देण्याची गरज का आहे? आम्ही आमचे सर्वोत्तम प्रयत्न करत आहोत. आम्ही खरोखर शक्य तितके आणि सर्वोत्तम मार्गाने वितरित करण्याचा प्रयत्न करतो, परंतु आम्ही 100% हमी देत ​​नाही. म्हणून, तेथे आर्थिक डेटा लिहिण्याची आवश्यकता नाही. यासाठी व्यवहारांसह डेटाबेस आहेत.

आपला प्रश्न: जेव्हा API लॉगमध्ये काही संदेश व्युत्पन्न करते आणि मायक्रोसर्व्हिसेसमध्ये नियंत्रण हस्तांतरित करते, तेव्हा तुम्हाला समस्या आली आहे की वेगवेगळ्या मायक्रोसर्व्हिसेसचे संदेश चुकीच्या क्रमाने येतात? यामुळे गोंधळ निर्माण होतो.

उत्तर द्या: ते वेगवेगळ्या क्रमाने येतात हे सामान्य आहे. यासाठी तुम्हाला तयार राहावे लागेल. कारण कोणतेही नेटवर्क वितरण ऑर्डरची हमी देत ​​​​नाही, किंवा तुम्हाला यासाठी विशेष संसाधने खर्च करावी लागतील. आम्ही फाइल स्टोरेज घेतल्यास, प्रत्येक API त्याच्या स्वतःच्या फाइलमध्ये लॉग सेव्ह करते. किंवा त्याऐवजी, तेथे rsyslog त्यांना डिरेक्टरीमध्ये वर्गीकृत करते. प्रत्येक API चे स्वतःचे लॉग असतात, जिथे तुम्ही जाऊन पाहू शकता आणि नंतर तुम्ही या लॉगमधील टाइमस्टॅम्प वापरून त्यांची तुलना करू शकता. जर ते ग्रेलॉगमध्ये बघायला गेले, तर ते तेथे टाइमस्टॅम्पनुसार क्रमवारी लावलेले आहेत. तिथे सर्व काही ठीक होईल.

आपला प्रश्न: टाइमस्टॅम्प मिलिसेकंदानुसार बदलू शकतो.

उत्तर द्या: टाइमस्टॅम्प API द्वारेच तयार केला जातो. खरं तर, हा संपूर्ण मुद्दा आहे. आमच्याकडे NTP आहे. API संदेशामध्येच टाइमस्टॅम्प तयार करते. rsyslog ते जोडत नाही.

आपला प्रश्न: डेटा केंद्रांमधील परस्परसंवाद फारसा स्पष्ट नाही. डेटा सेंटरमध्ये, हे स्पष्ट आहे की लॉग कसे गोळा केले गेले आणि त्यावर प्रक्रिया केली गेली. डेटा केंद्रांमधील परस्परसंवाद कसा होतो? किंवा प्रत्येक डेटा सेंटर स्वतःचे आयुष्य जगतो?

उत्तर द्या: जवळजवळ. आपल्या देशात, प्रत्येक देश एका डेटा सेंटरमध्ये स्थित आहे. याक्षणी, आमच्याकडे स्प्रेड आउट नाही जेणेकरून एक देश वेगवेगळ्या डेटा सेंटरमध्ये आहे. म्हणून, त्यांना एकत्र करण्याची आवश्यकता नाही. प्रत्येक केंद्राच्या आत एक लॉग रिले आहे. हा Rsyslog सर्व्हर आहे. प्रत्यक्षात दोन व्यवस्थापन मशीन. त्यांचाही असाच दृष्टिकोन आहे. पण सध्या, रहदारी त्यापैकी एकावरून जाते. हे सर्व लॉग एकत्रित करते. तिला फक्त बाबतीत डिस्क रांग आहे. हे लॉग डाउनलोड करते आणि त्यांना सेंट्रल डेटा सेंटर (सिंगापूर) येथे पाठवते, जिथे ते नंतर ग्रेलॉगला पाठवले जातात. आणि प्रत्येक डेटा सेंटरचे स्वतःचे फाइल स्टोरेज असते. आमचे कनेक्शन तुटल्यास, आमच्याकडे सर्व लॉग आहेत. ते तिथेच राहतील. ते तिथे साठवले जातील.

आपला प्रश्न: असामान्य परिस्थितीत, तुम्हाला तिथून नोंदी मिळतात का?

उत्तर द्या: तुम्ही तिथे (फाइल स्टोरेजमध्ये) जाऊन पाहू शकता.

आपला प्रश्न: तुम्ही नोंदी गमावत नाही आहात याचे निरीक्षण कसे करता?

उत्तर द्या: आम्ही प्रत्यक्षात त्यांना गमावत आहोत, आणि आम्ही त्याचे निरीक्षण करत आहोत. महिनाभरापूर्वी देखरेख सुरू करण्यात आली. Go API वापरत असलेल्या लायब्ररीमध्ये मेट्रिक्स आहेत. ती किती वेळा सॉकेटवर लिहू शकली नाही ते मोजू शकते. तेथे सध्या एक हुशार ह्युरिस्टिक आहे. तेथे एक बफर आहे. त्यातून सॉकेटवर संदेश लिहिण्याचा प्रयत्न करतो. बफर ओव्हरफ्लो झाल्यास, ते त्यांना सोडण्यास सुरवात करते. आणि त्यापैकी किती सोडले याची तो मोजणी करतो. तेथे मीटर ओव्हरफ्लो होऊ लागल्यास त्याची माहिती मिळेल. ते आता प्रोमिथियसकडेही येत आहेत आणि तुम्ही ग्राफनामधील आलेख पाहू शकता. तुम्ही अलर्ट सेट करू शकता. मात्र ते कोणाकडे पाठवायचे हे अद्याप स्पष्ट झालेले नाही.

आपला प्रश्न: elasticsearch मध्ये तुम्ही रिडंडंसीसह लॉग स्टोअर करता. तुमच्याकडे किती प्रतिकृती आहेत?

उत्तर द्या: एक ओळ.

आपला प्रश्न: ही फक्त एक ओळ आहे का?

उत्तर द्या: हे गुरु आणि प्रतिकृती आहे. डेटा दोन प्रतींमध्ये संग्रहित केला जातो.

आपला प्रश्न: तुम्ही rsyslog बफर आकार कसा तरी समायोजित केला आहे का?

उत्तर द्या: आम्ही कस्टम युनिक्स सॉकेटवर डेटाग्राम लिहितो. हे ताबडतोब आमच्यावर 128 किलोबाइट्सची मर्यादा लादते. आम्ही त्यावर अधिक लिहू शकत नाही. आम्ही हे मानकात लिहिले आहे. ज्यांना स्टोरेजमध्ये जायचे आहे त्यांनी 128 किलोबाइट लिहा. लायब्ररी, शिवाय, कापल्या जातात आणि एक ध्वज ठेवला जातो की संदेश कापला जातो. संदेशासाठी आमच्या मानकामध्ये एक विशेष फील्ड आहे जे रेकॉर्डिंग दरम्यान कापले गेले की नाही हे दर्शविते. त्यामुळे या क्षणाचाही मागोवा घेण्याची संधी आमच्याकडे आहे.

प्रश्न: तुटलेली JSON लिहिता का?

उत्तर द्या: तुटलेला JSON एकतर रिले दरम्यान टाकून दिला जाईल कारण पॅकेट खूप मोठे आहे. किंवा ग्रेलॉग टाकून दिला जाईल कारण तो JSON पार्स करू शकत नाही. परंतु काही बारकावे आहेत ज्यांचे निराकरण करणे आवश्यक आहे आणि ते बहुतेक rsyslog शी जोडलेले आहेत. मी आधीच तेथे अनेक मुद्दे भरले आहेत, ज्यावर अजून काम करणे आवश्यक आहे.

प्रश्न: काफ्का का? तुम्ही RabbitMQ चा प्रयत्न केला आहे का? अशा भाराखाली ग्रेलॉग अयशस्वी होतो का?

उत्तर द्या: हे ग्रेलॉगसह आमच्यासाठी कार्य करत नाही. आणि ग्रेलॉग आमच्यासाठी आकार घेत आहे. तो खरोखर समस्याप्रधान आहे. तो एक विलक्षण गोष्ट आहे. आणि, खरं तर, त्याची गरज नाही. मी rsyslog वरून थेट elasticsearch वर लिहिण्यास प्राधान्य देईन आणि नंतर Kibana पहा. मात्र सुरक्षा रक्षकांसोबत हा प्रश्न सोडवायला हवा. जेव्हा आम्ही ग्रेलॉग बाहेर टाकतो आणि किबाना वापरतो तेव्हा आमच्या विकासासाठी हा एक संभाव्य पर्याय आहे. लॉगस्टॅश वापरण्यात काही अर्थ नाही. कारण मी हीच गोष्ट rsyslog सह करू शकतो. आणि त्यात elasticsearch लिहिण्यासाठी एक मॉड्यूल आहे. आम्ही ग्रेलॉगसह कसे तरी जगण्याचा प्रयत्न करीत आहोत. आम्ही ते थोडे ट्यून केले. पण अजूनही सुधारणेला वाव आहे.

काफ्का बद्दल. ऐतिहासिकदृष्ट्या हे असेच घडले. मी पोहोचलो तेव्हा ते आधीच तिथे होते आणि त्यावर नोंदी लिहिल्या जात होत्या. आम्ही फक्त आमचे क्लस्टर वाढवले ​​आणि त्यात लॉग हलवले. आम्ही त्याचे व्यवस्थापन आहोत, त्याला कसे वाटते ते आम्हाला माहित आहे. RabbitMQ साठी... ते RabbitMQ सह आमच्यासाठी कार्य करत नाही. आणि RabbitMQ आमच्यासाठी आकार घेत आहे. आमच्याकडे ते उत्पादनात आहे आणि त्यात काही समस्या होत्या. आता, विक्रीपूर्वी, ते त्याला मोहित करतील आणि तो सामान्यपणे काम करू शकेल. पण त्याआधी मी ते प्रोडक्शनमध्ये सोडायला तयार नव्हते. अजून एक मुद्दा आहे. ग्रेलॉग AMQP 0.9 आवृत्ती वाचू शकतो आणि rsyslog AMQP 1.0 आवृत्ती लिहू शकतो. आणि मधला एकच उपाय नाही जो दोन्ही करू शकेल. हे एकतर एक किंवा दुसरे आहे. त्यामुळे सध्या फक्त काफ्का. पण त्याचे स्वतःचे बारकावे देखील आहेत. कारण आम्ही वापरत असलेल्या rsyslog च्या आवृत्तीचा omkafka rsyslog मधून काढलेला संपूर्ण संदेश बफर गमावू शकतो. सध्या आम्ही ते सहन केले.

प्रश्न: तुम्ही काफ्का वापरत आहात कारण तुमच्याकडे आधीच होता? यापुढे कोणत्याही कारणासाठी वापरले जात नाही?

उत्तर द्या: काफ्का, जो डेटा सायन्स टीमद्वारे वापरला जातो. हा एक पूर्णपणे वेगळा प्रकल्प आहे, ज्याबद्दल, दुर्दैवाने, मी काहीही बोलू शकत नाही. मला माहित नाही. हे डेटा सायन्स टीमने चालवले होते. जेव्हा लॉग तयार केले गेले, तेव्हा आम्ही ते वापरण्याचे ठरवले जेणेकरून ते स्वतःचे स्थापित करू नये. आता आम्ही ग्रेलॉग अद्यतनित केले आहे, आणि आम्ही सुसंगतता गमावली आहे कारण त्यात काफ्काची जुनी आवृत्ती आहे. सुरुवात स्वतःपासून करायची होती. त्याच वेळी, आम्ही प्रत्येक API साठी या चार विषयांपासून मुक्त झालो. आम्ही सर्व लाइव्हसाठी एक विस्तृत विषय बनवला आहे, सर्व स्टेजिंगसाठी एक विस्तृत विषय तयार केला आहे आणि सर्वकाही तिथे ठेवले आहे. ग्रेलॉग हे सर्व समांतरपणे स्क्रॅप करते.

प्रश्न: आम्हाला सॉकेटसह या शमनवादाची गरज का आहे? तुम्ही कंटेनरसाठी syslog लॉग ड्रायव्हर वापरण्याचा प्रयत्न केला आहे का?

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

प्रश्न: तुम्ही rsyslog वापरून डेटा सेंटर दरम्यान डिलिव्हरी करता. काफ्का का नाही?

उत्तर द्या: खरं तर आम्ही दोन्ही करतो. दोन कारणांसाठी. जर चॅनेल पूर्णपणे मृत असेल, तर आमचे सर्व लॉग, अगदी संकुचित स्वरूपातही, त्यातून क्रॉल होणार नाहीत. आणि काफ्का तुम्हाला प्रक्रियेत त्यांना फक्त गमावण्याची परवानगी देतो. अशा प्रकारे आपण अडकलेल्या या लॉगपासून मुक्त होतो. आम्ही या प्रकरणात थेट काफ्का वापरत आहोत. जर आमच्याकडे चांगले चॅनल असेल आणि ते मोकळे करायचे असेल तर आम्ही त्यांचा rsyslog वापरतो. परंतु खरं तर, आपण ते कॉन्फिगर करू शकता जेणेकरून ते स्वतःच जे बसत नाही ते ड्रॉप करेल. या क्षणी, आम्ही फक्त कुठेतरी थेट rsyslog डिलिव्हरी वापरतो आणि काफ्का कुठेतरी.

स्त्रोत: www.habr.com