👨🏿‍💻 🌧️ 🧛🏽 कुबेरनेट्स में लॉग्स (और न केवल) आज: उम्मीदें और वास्तविकता 🖖🏾 🏤 👩‍🎨

यह 2019 था, और हमारे पास अभी भी कुबेरनेट्स में लॉग एकत्रीकरण के लिए एक मानक समाधान नहीं है। इस लेख में, हम चाहेंगे कि वास्तविक अभ्यासों के उदाहरणों का उपयोग करके, अपनी खोजों को साझा करने में, समस्याओं और उनके समाधानों को साझा किया जाए।

हालाँकि, के साथ शुरू करने के लिए, मैं एक आरक्षण करूँगा कि विभिन्न ग्राहक लॉग एकत्र करके बहुत अलग चीजों को समझें:

कोई व्यक्ति सुरक्षा और ऑडिट लॉग देखना चाहता है;
कोई - पूरे बुनियादी ढांचे का केंद्रीकृत लॉगिंग;
और किसी के लिए यह केवल आवेदन लॉग को इकट्ठा करने के लिए पर्याप्त है, उदाहरण के लिए, balancers।

कट के तहत हमने विभिन्न "विशलिस्ट" को कैसे लागू किया और हमें किन कठिनाइयों का सामना करना पड़ा।

थ्योरी: लॉगिंग टूल्स के बारे में

लॉगिंग सिस्टम के घटकों पर पृष्ठभूमि

लॉगिंग एक लंबा सफर तय कर चुकी है, जिसके परिणामस्वरूप हमने लॉग इकट्ठा करने और उनका विश्लेषण करने के लिए कार्यप्रणाली विकसित की है, जिसका उपयोग हम आज करते हैं। 1950 के दशक में, फोरट्रान ने मानक I / O धाराओं का एक एनालॉग पेश किया जिसने प्रोग्रामर को अपने कार्यक्रम को डिबग करने में मदद की। ये पहले कंप्यूटर लॉग थे जिन्होंने उस समय के प्रोग्रामर के लिए जीवन को आसान बना दिया था। आज हम उन्हें लॉगिंग सिस्टम के पहले घटक - लॉग के स्रोत या "निर्माता" के रूप में देखते हैं ।

कंप्यूटर विज्ञान अभी भी खड़ा नहीं था: कंप्यूटर नेटवर्क दिखाई दिया, पहला क्लस्टर ... कई कंप्यूटरों से मिलकर जटिल सिस्टम काम करना शुरू कर दिया। अब सिस्टम प्रशासकों को कई मशीनों से लॉग इकट्ठा करने के लिए मजबूर किया गया था, और विशेष मामलों में वे सिस्टम की विफलता की जांच करने के लिए आवश्यक होने पर ओएस कर्नेल संदेश जोड़ सकते थे। केंद्रीकृत लॉग संग्रह प्रणालियों का वर्णन करने के लिए, आरएफसी 3164 2000 के दशक की शुरुआत में सामने आया, जिसने रिमोट_साइलॉग को मानकीकृत किया। तो एक और महत्वपूर्ण घटक दिखाई दिया: लॉग का कलेक्टर (कलेक्टर) और उनका भंडारण।

लॉग की मात्रा में वृद्धि और वेब प्रौद्योगिकियों के व्यापक रूप से अपनाने के साथ, यह सवाल उठता है कि कौन से लॉग को उपयोगकर्ताओं को आसानी से दिखाया जाना चाहिए। साधारण कंसोल टूल्स (awk / sed / grep) को और अधिक उन्नत लॉग दर्शकों द्वारा प्रतिस्थापित किया गया - तीसरा घटक।

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

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

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

नतीजतन, अपेक्षाकृत कम समय के लिए, लॉग का संग्रह एक महत्वपूर्ण उप-प्रणाली में विकसित हुआ है, जिसे बिग डेटा में एक उप-वर्ग कहा जा सकता है।

अगर एक बार साधारण प्रिंट एक "लॉगिंग सिस्टम" के लिए पर्याप्त हो सकता है, तो अब स्थिति बहुत बदल गई है।

कुबेरनेट्स और लॉग्स

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

आगे देखते हुए, मैं कह सकता हूं कि अब, दुर्भाग्य से, कुबेरनेट्स के लिए कोई मानकीकृत लॉगिंग विकल्प नहीं है जो सभी के साथ अनुकूल रूप से तुलना करेगा। समुदाय में सबसे लोकप्रिय योजनाएं इस प्रकार हैं:

कोई व्यक्ति EFK स्टैक (एलियस्टिक्स खोज, फ्लुएंट, किबाना) तैनात कर रहा है;
कोई व्यक्ति हाल ही में जारी लोकी या लॉगिंग ऑपरेटर का उपयोग करने की कोशिश कर रहा है;
हम (और शायद केवल हम ही नहीं? ..) बड़े पैमाने पर हमारे अपने विकास से संतुष्ट हैं - लॉगहाउस ...

एक नियम के रूप में, हम K8s क्लस्टर्स में (स्व-होस्ट किए गए समाधानों के लिए) ऐसे बंडलों का उपयोग करते हैं:

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

K8s में लॉग के साथ अभ्यास करें

"हर दिन लॉग", आप में से कितने?

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

चलिए ClickHouse आजमाते हैं

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

जैसे ही अधिकतम वास्तविक समय की आवश्यकता होती है, 4-कोर ClickHouse सर्वर पहले से ही डिस्क सबसिस्टम पर अतिभारित हो जाएगा:

इस प्रकार का डाउनलोड इस तथ्य के कारण है कि हम जल्द से जल्द ClickHouse पर लिखने की कोशिश कर रहे हैं। और डेटाबेस बढ़े हुए डिस्क लोड के साथ इसका जवाब देता है, जिससे निम्नलिखित त्रुटियां हो सकती हैं:

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

तथ्य यह है कि ClickHouse में मर्जट्री टेबल (उनके पास लॉग डेटा है) लिखने के संचालन के दौरान उनकी अपनी कठिनाइयां हैं। उनमें डाला गया डेटा एक अस्थायी विभाजन उत्पन्न करता है, जो तब मुख्य तालिका के साथ विलीन हो जाता है। नतीजतन, रिकॉर्डिंग डिस्क पर बहुत मांग है, और प्रतिबंध उस पर लागू होता है, जिसकी अधिसूचना हमें प्राप्त हुई थी: 300 से अधिक सबपार्टिशन 1 सेकंड में विलय नहीं हो सकते हैं (वास्तव में, यह प्रति सेकंड 300 डालने है)।

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

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

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

Elasticsearch के बारे में क्या?

एलिटिक्स खोज को भारी भार को संभालने के लिए जाना जाता है। आइए इसे उसी प्रोजेक्ट में आज़माते हैं। अब लोड निम्नानुसार है:

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

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

फिर एक तार्किक सवाल उठता है:

क्या लॉग वास्तव में जरूरत है?

आइए दृष्टिकोण को स्वयं बदलने का प्रयास करें: लॉग एक ही समय में जानकारीपूर्ण होना चाहिए, और सिस्टम में प्रत्येक घटना को कवर नहीं करना चाहिए।

मान लीजिए कि हमारे पास एक समृद्ध ऑनलाइन स्टोर है। कौन से लॉग महत्वपूर्ण हैं? अधिक से अधिक जानकारी इकट्ठा करना, उदाहरण के लिए, भुगतान गेटवे से एक महान विचार है। लेकिन उत्पाद कैटलॉग में छवि स्लाइसिंग सेवा से, सभी लॉग हमारे लिए महत्वपूर्ण नहीं हैं: केवल त्रुटियां और उन्नत निगरानी पर्याप्त है (उदाहरण के लिए, 500 त्रुटियों का प्रतिशत जो यह घटक उत्पन्न करता है)।

इसलिए हम इस निष्कर्ष पर पहुंचे कि केंद्रीकृत लॉगिंग हमेशा के लिए उचित है । बहुत बार, क्लाइंट सभी लॉग्स को एक जगह इकट्ठा करना चाहता है, हालांकि वास्तव में व्यापार के लिए महत्वपूर्ण संदेशों में से केवल 5% पूरे लॉग से आवश्यक हैं:

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

जीवन चित्रण

एक अच्छा उदाहरण एक और कहानी है। हमें उन ग्राहकों में से एक की सुरक्षा टीम से अनुरोध प्राप्त हुआ, जिनके पास पहले से ही एक वाणिज्यिक समाधान था जो कुबेरनेट के कार्यान्वयन से बहुत पहले विकसित किया गया था।

समस्याओं का पता लगाने के लिए कॉरपोरेट सेंसर के साथ एक केंद्रीकृत लॉग संग्रह प्रणाली को "दोस्त बनाने" के लिए लिया गया - क्यूराडार। यह सिस्टम 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 के लिए प्रस्तावित / चर्चा की गई सामान्य लॉग संग्रह योजनाओं में समस्याएं हैं।

उदाहरण के लिए, फ्लुएंट अल्पकालिक कंटेनरों से लॉग एकत्र नहीं कर सकता है। हमारी एक परियोजना में, डेटाबेस माइग्रेशन वाला कंटेनर 4 सेकंड से कम समय के लिए रहता था, और फिर इसी एनोटेशन के अनुसार हटा दिया गया था:

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

इस वजह से, माइग्रेशन लॉग रिपॉजिटरी में नहीं गया। before-hook-creation नीति इस मामले में मदद कर सकती है।

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

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

अंत में, यह मत भूलो कि गुणवत्ता में किसी भी सबसिस्टम की निगरानी करना महत्वपूर्ण है । अन्यथा, ऐसी स्थिति का सामना करना आसान है, जिसमें CrashLoopBackOff राज्य में CrashLoopBackOff है और कुछ भी नहीं भेजता है, और यह महत्वपूर्ण जानकारी के नुकसान का वादा करता है।

निष्कर्ष

इस लेख में, हम दातादोग जैसे सास समाधान पर विचार नहीं करते हैं। यहां वर्णित समस्याओं में से कई पहले से ही एक तरह से या किसी अन्य में वाणिज्यिक कंपनियों द्वारा लॉग को इकट्ठा करने में विशेषज्ञता प्राप्त हैं, लेकिन हर कोई विभिन्न कारणों के लिए सास का उपयोग नहीं कर सकता है (मुख्य लागत 152-here के साथ लागत और अनुपालन हैं) ।

पहले लॉग पर केंद्रीकृत संग्रह एक साधारण कार्य की तरह दिखता है, लेकिन यह बिल्कुल भी नहीं है। यह याद रखना महत्वपूर्ण है कि:

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

ये सरल नियम, अगर हर जगह लागू होते हैं, तो ऊपर वर्णित सर्किट काम करने की अनुमति देगा - भले ही उनके पास महत्वपूर्ण घटकों (बैटरी) की कमी हो। यदि आप ऐसे सिद्धांतों का पालन नहीं करते हैं, तो कार्य आपको आसानी से और बुनियादी ढांचे को सिस्टम के एक और अत्यधिक लोड (और एक ही समय अप्रभावी) घटक में ले जाएगा।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

कुबेरनेट्स में लॉग्स (और न केवल) आज: उम्मीदें और वास्तविकता