कुबर्नेट्स (आणि फक्त नाही) आज लॉग इन करा: अपेक्षा आणि वास्तव

हे 2019 आहे आणि आमच्याकडे अजूनही Kubernetes मध्ये लॉग एकत्रीकरणासाठी मानक उपाय नाही. या लेखात, आम्ही वास्तविक सरावातील उदाहरणे वापरून आमचे शोध, आलेल्या समस्या आणि त्यांचे निराकरण सामायिक करू इच्छितो.

तथापि, प्रथम, मी एक आरक्षण करेन की भिन्न ग्राहकांना लॉग गोळा करून खूप भिन्न गोष्टी समजतात:

• एखाद्याला सुरक्षा आणि ऑडिट लॉग पहायचे आहेत;
• कोणीतरी - संपूर्ण पायाभूत सुविधांचे केंद्रीकृत लॉगिंग;
• आणि काहींसाठी, फक्त ऍप्लिकेशन लॉग गोळा करणे पुरेसे आहे, उदाहरणार्थ, बॅलन्सर वगळता.

आम्ही विविध "इच्छा सूची" कशा लागू केल्या आणि आम्हाला कोणत्या अडचणी आल्या याबद्दल खाली कट आहे.

सिद्धांत: लॉगिंग साधनांबद्दल

लॉगिंग सिस्टमच्या घटकांची पार्श्वभूमी

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

संगणक विज्ञान स्थिर राहिले नाही: संगणक नेटवर्क दिसू लागले, पहिले क्लस्टर्स... अनेक संगणकांचा समावेश असलेल्या जटिल प्रणालींनी कार्य करण्यास सुरुवात केली. आता सिस्टीम प्रशासकांना अनेक मशीन्समधून लॉग गोळा करण्यास भाग पाडले गेले, आणि विशेष प्रकरणांमध्ये त्यांना सिस्टम बिघाडाची तपासणी करणे आवश्यक असल्यास ते OS कर्नल संदेश जोडू शकतात. केंद्रीकृत लॉग संग्रह प्रणालीचे वर्णन करण्यासाठी, 2000 च्या दशकाच्या सुरुवातीस ते प्रकाशित झाले आरएफसी 3164, जे प्रमाणित remote_syslog. आणखी एक महत्त्वाचा घटक अशा प्रकारे दिसला: लॉग कलेक्टर आणि त्यांचे स्टोरेज.

लॉगचे प्रमाण वाढल्याने आणि वेब तंत्रज्ञानाच्या व्यापक परिचयामुळे, वापरकर्त्यांना कोणते लॉग सोयीस्करपणे दर्शविले जावेत असा प्रश्न निर्माण झाला. साधी कन्सोल साधने (awk/sed/grep) अधिक प्रगत साधनांनी बदलली आहेत लॉग दर्शक - तिसरा घटक.

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

स्टोरेजने देखील मोठी झेप घेतली आहे: नियमित फाइल्सपासून रिलेशनल डेटाबेसेस आणि नंतर दस्तऐवज-देणारं स्टोरेज (उदाहरणार्थ, Elasticsearch). त्यामुळे साठवणूक कलेक्टरपासून वेगळी करण्यात आली.

शेवटी, लॉगची संकल्पना एका प्रकारच्या अमूर्त प्रवाहात विस्तारली आहे जी आपल्याला इतिहासासाठी जतन करायची आहे. किंवा त्याऐवजी, जर तुम्हाला तपास करावा लागेल किंवा विश्लेषणात्मक अहवाल तयार करावा लागेल...

परिणामी, तुलनेने कमी कालावधीत, लॉग संग्रह एक महत्त्वपूर्ण उपप्रणालीमध्ये विकसित झाला आहे, ज्याला बिग डेटामधील उपविभागांपैकी एक म्हणता येईल.

जर एकेकाळी "लॉगिंग सिस्टम" साठी सामान्य प्रिंट्स पुरेसे असतील तर आता परिस्थिती खूप बदलली आहे.

कुबर्नेट्स आणि लॉग

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

पुढे पाहताना, मी सांगू शकतो की आता, दुर्दैवाने, कुबर्नेट्ससाठी कोणताही प्रमाणित लॉगिंग पर्याय नाही जो इतर सर्वांशी अनुकूलपणे तुलना करेल. समाजातील सर्वात लोकप्रिय योजना खालीलप्रमाणे आहेत:

• कोणीतरी स्टॅक अनरोल करतो EFK (Elasticsearch, Fluentd, Kibana);
• कोणीतरी अलीकडे रिलीझ करण्याचा प्रयत्न करीत आहे लोकी किंवा वापरते लॉगिंग ऑपरेटर;
• нас (आणि कदाचित फक्त आम्हीच नाही?..) मी माझ्या स्वतःच्या विकासावर मोठ्या प्रमाणात समाधानी आहे - लॉगहाऊस...

नियमानुसार, आम्ही K8s क्लस्टर्समध्ये खालील बंडल वापरतो (स्वयं-होस्ट केलेल्या उपायांसाठी):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + लॉगहाऊस.

तथापि, मी त्यांच्या स्थापनेसाठी आणि कॉन्फिगरेशनच्या सूचनांवर लक्ष ठेवणार नाही. त्याऐवजी, मी त्यांच्या कमतरतांवर आणि सर्वसाधारणपणे लॉगसह परिस्थितीबद्दल अधिक जागतिक निष्कर्षांवर लक्ष केंद्रित करेन.

K8 मध्ये लॉगसह सराव करा

"दररोज नोंदी", तुमच्यापैकी किती आहेत?..

बऱ्यापैकी मोठ्या पायाभूत सुविधांमधून लॉगच्या केंद्रीकृत संकलनासाठी मोठ्या प्रमाणात संसाधने आवश्यक आहेत, जी लॉग गोळा करणे, संग्रहित करणे आणि त्यावर प्रक्रिया करणे यासाठी खर्च केले जातील. विविध प्रकल्पांच्या संचालनादरम्यान, आम्हाला विविध आवश्यकता आणि त्यांच्यामुळे उद्भवलेल्या ऑपरेशनल समस्यांचा सामना करावा लागला.

चला क्लिकहाऊस वापरून पाहू

चला एका प्रोजेक्टवर एका ऍप्लिकेशनसह केंद्रीकृत स्टोरेज पाहू जे सक्रियपणे लॉग व्युत्पन्न करते: प्रति सेकंद 5000 पेक्षा जास्त ओळी. चला त्याच्या लॉगसह कार्य करण्यास प्रारंभ करूया, त्यांना क्लिकहाऊसमध्ये जोडूया.

जितक्या लवकर जास्तीत जास्त रिअलटाइम आवश्यक असेल तितक्या लवकर, क्लिकहाऊससह 4-कोर सर्व्हर डिस्क सबसिस्टमवर आधीच ओव्हरलोड होईल:

या प्रकारचे लोडिंग आम्ही क्लिकहाऊसमध्ये शक्य तितक्या लवकर लिहिण्याचा प्रयत्न करत आहोत या वस्तुस्थितीमुळे आहे. आणि डेटाबेस वाढलेल्या डिस्क लोडसह यावर प्रतिक्रिया देतो, ज्यामुळे खालील त्रुटी येऊ शकतात:

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

पॉइंट आहे विलीन ट्री टेबल क्लिकहाऊसमध्ये (त्यात लॉग डेटा असतो) लेखन ऑपरेशन्स दरम्यान त्यांच्या स्वतःच्या अडचणी असतात. त्यात घातलेला डेटा एक तात्पुरता विभाजन तयार करतो, जो नंतर मुख्य सारणीमध्ये विलीन केला जातो. परिणामी, डिस्कवर रेकॉर्डिंग खूप मागणी असल्याचे दिसून आले, आणि आम्हाला वरील सूचना प्राप्त झालेल्या मर्यादेच्या अधीन देखील आहे: 1 सेकंदात 300 पेक्षा जास्त उपविभाजन विलीन केले जाऊ शकत नाहीत (खरं तर, हे 300 समाविष्ट आहेत. प्रती सेकंदास).

हे वर्तन टाळण्यासाठी, क्लिकहाऊसवर लिहावे शक्य तितक्या मोठ्या तुकड्यांमध्ये आणि प्रत्येक 1 सेकंदात 2 वेळापेक्षा जास्त नाही. तथापि, मोठ्या प्रमाणात लिहिणे सूचित करते की आपण क्लिकहाऊसमध्ये कमी वेळा लिहावे. यामुळे, बफर ओव्हरफ्लो होऊ शकते आणि लॉगचे नुकसान होऊ शकते. Fluentd बफर वाढवणे हा उपाय आहे, परंतु नंतर मेमरी वापर देखील वाढेल.

शेरा: ClickHouse सह आमच्या सोल्यूशनचा आणखी एक समस्याप्रधान पैलू या वस्तुस्थितीशी संबंधित होता की आमच्या केसमध्ये (लॉगहाउस) विभाजन जोडलेल्या बाह्य सारण्यांद्वारे लागू केले जाते. टेबल विलीन करा. हे या वस्तुस्थितीला कारणीभूत ठरते की मोठ्या वेळेच्या अंतराचा नमुना घेताना, जास्त RAM आवश्यक असते, कारण मेटाटेबल सर्व विभाजनांमधून पुनरावृत्ती होते - अगदी स्पष्टपणे आवश्यक डेटा नसलेल्या देखील. तथापि, आता हा दृष्टिकोन ClickHouse च्या वर्तमान आवृत्त्यांसाठी सुरक्षितपणे अप्रचलित घोषित केला जाऊ शकतो (c 18.16).

परिणामी, हे स्पष्ट होते की क्लिकहाऊसमध्ये रिअल टाइममध्ये लॉग गोळा करण्यासाठी प्रत्येक प्रकल्पाकडे पुरेशी संसाधने नाहीत (अधिक स्पष्टपणे, त्यांचे वितरण योग्य होणार नाही). याव्यतिरिक्त, आपल्याला वापरण्याची आवश्यकता असेल аккумулятор, ज्याकडे आम्ही नंतर परत येऊ. वर वर्णन केलेली केस खरी आहे. आणि त्या वेळी आम्ही ग्राहकाला अनुकूल असा विश्वासार्ह आणि स्थिर उपाय देऊ शकलो नाही आणि आम्हाला किमान विलंबाने नोंदी गोळा करण्यास अनुमती देईल...

Elasticsearch बद्दल काय?

Elasticsearch हे जड वर्कलोड हाताळण्यासाठी ओळखले जाते. चला त्याच प्रकल्पात प्रयत्न करूया. आता लोड असे दिसते:

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

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

मग एक नैसर्गिक प्रश्न उद्भवतो:

खरोखर कोणत्या नोंदी आवश्यक आहेत?

चला दृष्टीकोन बदलण्याचा प्रयत्न करूया: लॉग एकाच वेळी माहितीपूर्ण असले पाहिजेत आणि कव्हर करू नयेत प्रत्येक सिस्टममधील घटना.

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

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

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

जीवनातून चित्रण

दुसरी कथा उत्तम उदाहरण म्हणून काम करू शकते. आम्हाला आमच्या एका क्लायंटच्या सुरक्षा टीमकडून विनंती प्राप्त झाली आहे जो आधीपासूनच व्यावसायिक उपाय वापरत होता जो कुबर्नेट्सच्या परिचयाच्या खूप आधी विकसित झाला होता.

कॉर्पोरेट प्रॉब्लेम डिटेक्शन सेन्सर - QRadar सह केंद्रीकृत लॉग कलेक्शन सिस्टमचे "मित्र बनवणे" आवश्यक होते. ही प्रणाली syslog प्रोटोकॉलद्वारे लॉग प्राप्त करू शकते आणि त्यांना FTP वरून पुनर्प्राप्त करू शकते. तथापि, ते fluentd साठी remote_syslog प्लगइनसह समाकलित करणे त्वरित शक्य नव्हते. (जसे झाले की, आपण एकटे नाही आहोत). QRadar सेट करण्यात समस्या क्लायंटच्या सुरक्षा टीमच्या बाजूने असल्याचे दिसून आले.

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

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

लॉगसाठी निकष

अशा उदाहरणांमुळे असा निष्कर्ष निघतो की लॉग कलेक्शन सिस्टम निवडण्याव्यतिरिक्त, आपल्याला आवश्यक आहे लॉग स्वतः डिझाइन करा! येथे आवश्यकता काय आहेत?

• लॉग मशीन-वाचनीय फॉरमॅटमध्ये असणे आवश्यक आहे (उदाहरणार्थ, JSON).
• लॉग कॉम्पॅक्ट आणि संभाव्य समस्या डीबग करण्यासाठी लॉगिंगची डिग्री बदलण्याची क्षमता असावी. त्याच वेळी, उत्पादन वातावरणात तुम्ही लॉगिंग पातळी सारख्या प्रणाली चालवाव्यात चेतावणी किंवा त्रुटी.
• लॉग सामान्य करणे आवश्यक आहे, म्हणजेच, लॉग ऑब्जेक्टमध्ये, सर्व ओळींमध्ये समान फील्ड प्रकार असणे आवश्यक आहे.

अनस्ट्रक्चर्ड लॉगमुळे स्टोरेजमध्ये लॉग लोड करण्यात समस्या निर्माण होतात आणि त्यांची प्रक्रिया पूर्ण थांबते. उदाहरण म्हणून, येथे त्रुटी 400 सह एक उदाहरण आहे, जे बर्‍याच जणांना निश्चितपणे अस्खलित लॉगमध्ये आढळले आहे:

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

त्रुटीचा अर्थ असा आहे की तुम्ही एक फील्ड पाठवत आहात ज्याचा प्रकार रेडीमेड मॅपिंगसह इंडेक्समध्ये अस्थिर आहे. सर्वात सोपं उदाहरण म्हणजे व्हेरिएबलसह nginx लॉगमधील फील्ड $upstream_status. त्यात एकतर संख्या किंवा स्ट्रिंग असू शकते. उदाहरणार्थ:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

नोंदी दाखवतात की सर्व्हर 10.100.0.10 ने 404 त्रुटीसह प्रतिसाद दिला आणि विनंती दुसर्‍या सामग्री संचयनावर पाठवली गेली. परिणामी, लॉगमधील मूल्य असे झाले:

"upstream_response_time": "0.001, 0.007"

ही परिस्थिती इतकी सामान्य आहे की ती वेगळी आहे दस्तऐवजीकरणातील संदर्भ.

विश्वासार्हतेबद्दल काय?

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

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

"helm.sh/hook-delete-policy": hook-succeeded

यामुळे, माइग्रेशन एक्झिक्यूशन लॉग स्टोरेजमध्ये समाविष्ट केले गेले नाही. या प्रकरणात राजकारण मदत करू शकते. before-hook-creation.

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

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

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

निष्कर्ष

या लेखात, आम्ही Datadog सारखे SaaS उपाय पाहत नाही आहोत. येथे वर्णन केलेल्या अनेक समस्या आधीच लॉग गोळा करण्यात तज्ञ असलेल्या व्यावसायिक कंपन्यांनी एक किंवा दुसर्या मार्गाने सोडवल्या आहेत, परंतु प्रत्येकजण विविध कारणांसाठी SaaS वापरू शकत नाही. (मुख्य म्हणजे किंमत आणि 152-FZ चे अनुपालन).

केंद्रीकृत लॉग संग्रह प्रथम एक साध्या कार्यासारखे दिसते, परंतु ते अजिबात नाही. हे लक्षात ठेवणे महत्वाचे आहे की:

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

हे साधे नियम, सर्वत्र लागू केले असल्यास, वर वर्णन केलेल्या सर्किट्सना कार्य करण्यास अनुमती मिळेल - जरी ते महत्त्वाचे घटक (बॅटरी) गहाळ असले तरीही. आपण अशा तत्त्वांचे पालन न केल्यास, कार्य सहजपणे आपल्याला आणि पायाभूत सुविधांना सिस्टमच्या दुसर्या अत्यंत भारित (आणि त्याच वेळी अप्रभावी) घटकाकडे नेईल.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «लॉगहाऊस सादर करत आहे - कुबर्नेट्समधील लॉगसह कार्य करण्यासाठी एक मुक्त स्रोत प्रणाली";
• «KubeCon’19 वरून कुबर्नेट्स इकोसिस्टमसाठी रिलीज: JFrog कंटेनर रजिस्ट्री, IBM कडून Kui, Loki 1.0.0…";
• «देखरेख आणि कुबर्नेट्स (पुनरावलोकन आणि व्हिडिओ अहवाल)».

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