Kubernetes मा लग (र मात्र होइन) आज: अपेक्षा र वास्तविकता

यो 2019 हो, र हामीसँग अझै पनि Kubernetes मा लग एग्रीगेसनको लागि मानक समाधान छैन। यस लेखमा, हामी, वास्तविक अभ्यासबाट उदाहरणहरू प्रयोग गरेर, हाम्रा खोजहरू, सामना गरिएका समस्याहरू र तिनीहरूका समाधानहरू साझा गर्न चाहन्छौं।

यद्यपि, पहिले, म एउटा रिजर्भेसन गर्नेछु कि विभिन्न ग्राहकहरूले लगहरू सङ्कलन गरेर धेरै फरक कुराहरू बुझ्छन्:

• कसैले सुरक्षा र अडिट लगहरू हेर्न चाहन्छ;
• कोही - सम्पूर्ण पूर्वाधारको केन्द्रीकृत लगिङ;
• र केहि को लागी, यो केवल अनुप्रयोग लगहरू संकलन गर्न पर्याप्त छ, बाहेक, उदाहरणका लागि, ब्यालेन्सरहरू।

हामीले कसरी विभिन्न "इच्छा सूचीहरू" लागू गर्यौं र हामीले सामना गरेका कठिनाइहरूको बारेमा तल काटिएको छ।

सिद्धान्त: लगिङ उपकरण बारे

लगिङ प्रणालीको कम्पोनेन्टहरूमा पृष्ठभूमि

लगिङ एक लामो बाटो आइपुगेको छ, जसको फलस्वरूप लगहरू सङ्कलन र विश्लेषण गर्ने विधिहरू विकसित भएका छन्, जुन हामी आज प्रयोग गर्छौं। 1950 को दशकमा, फोरट्रानले मानक इनपुट/आउटपुट स्ट्रिमहरूको एनालग प्रस्तुत गर्‍यो, जसले प्रोग्रामरलाई आफ्नो कार्यक्रम डिबग गर्न मद्दत गर्‍यो। यी पहिलो कम्प्युटर लगहरू थिए जसले ती समयका प्रोग्रामरहरूको लागि जीवन सजिलो बनायो। आज हामी तिनीहरूमा लगिङ प्रणालीको पहिलो घटक देख्छौं - स्रोत वा लगहरूको "उत्पादक".

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

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

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

भण्डारणले पनि ठूलो फड्को मारेको छ: नियमित फाइलहरूबाट रिलेशनल डाटाबेसहरूमा, र त्यसपछि कागजात-उन्मुख भण्डारणमा (उदाहरणका लागि, Elasticsearch)। त्यसैले भण्डारण कलेक्टरबाट अलग गरिएको थियो।

अन्ततः, लगको अवधारणा एक प्रकारको अमूर्त स्ट्रिममा विस्तार भएको छ जुन हामी इतिहासको लागि सुरक्षित गर्न चाहन्छौं। वा बरु, यदि तपाइँ एक अनुसन्धान सञ्चालन गर्न वा विश्लेषणात्मक रिपोर्ट कोर्न आवश्यक छ भने ...

नतिजाको रूपमा, अपेक्षाकृत छोटो अवधिमा, लग सङ्कलन एक महत्त्वपूर्ण उपप्रणालीको रूपमा विकसित भएको छ, जसलाई सही रूपमा बिग डाटाको उपखण्डहरू मध्ये एक भन्न सकिन्छ।

यदि कुनै समय सामान्य प्रिन्टहरू "लगिङ प्रणाली" को लागी पर्याप्त हुन सक्छ, अब स्थिति धेरै परिवर्तन भएको छ।

Kubernetes र लगहरू

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

अगाडि हेर्दै, म यो बताउन सक्छु कि अब, दुर्भाग्यवश, त्यहाँ Kubernetes को लागी कुनै मानकीकृत लगिङ विकल्प छैन जुन अन्य सबै संग अनुकूल तुलना हुनेछ। समुदायमा सबैभन्दा लोकप्रिय योजनाहरू निम्नानुसार छन्:

• कसैले स्ट्याक खोल्छ EFK (Elasticsearch, Fluentd, Kibana);
• कसैले हालै जारी गरेको प्रयास गर्दैछ लोकी वा प्रयोग गर्दछ लगिङ अपरेटर;
• нас (र सायद हामी मात्र होइन? ..) म मेरो आफ्नै विकास संग धेरै हदसम्म सन्तुष्ट छु - लग घर...

नियमको रूपमा, हामी K8s क्लस्टरहरूमा निम्न बन्डलहरू प्रयोग गर्छौं (स्व-होस्ट गरिएको समाधानहरूको लागि):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + Loghouse.

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

K8s मा लगहरूसँग अभ्यास गर्नुहोस्

"दैनिक लग", तपाईहरु मध्ये कति जना हुनुहुन्छ?...

पर्याप्त ठूलो पूर्वाधारबाट लगहरूको केन्द्रीकृत सङ्कलनलाई पर्याप्त स्रोतहरू चाहिन्छ, जुन लगहरू सङ्कलन, भण्डारण र प्रशोधनमा खर्च गरिनेछ। विभिन्न आयोजना सञ्चालनका क्रममा हामीले विभिन्न आवश्यकता र त्यसबाट उत्पन्न हुने सञ्चालन समस्याको सामना गर्नुपरेको थियो ।

क्लिकहाउस प्रयास गरौं

एप्लिकेसनको साथ एक परियोजनामा ​​केन्द्रीकृत भण्डारण हेरौं जुन धेरै सक्रिय रूपमा लगहरू उत्पन्न गर्दछ: प्रति सेकेन्ड 5000 भन्दा बढी लाइनहरू। क्लिकहाउसमा थप्दै उसको लगहरूसँग काम सुरु गरौं।

अधिकतम वास्तविक समय आवश्यक हुने बित्तिकै, क्लिकहाउसको साथ 4-कोर सर्भर पहिले नै डिस्क सबसिस्टममा ओभरलोड हुनेछ:

यस प्रकारको लोडिङ यस तथ्यको कारण हो कि हामी क्लिकहाउसमा जतिसक्दो चाँडो लेख्न खोजिरहेका छौं। र डाटाबेसले बढेको डिस्क लोडको साथ यसमा प्रतिक्रिया गर्दछ, जसले निम्न त्रुटिहरू निम्त्याउन सक्छ:

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

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

यस्तो व्यवहारबाट बच्न, क्लिकहाउसमा लेख्नुपर्छ सकेसम्म ठूला टुक्राहरूमा र प्रत्येक 1 सेकेन्डमा 2 पटक भन्दा बढी। यद्यपि, ठूला बर्स्टहरूमा लेख्दा हामीले क्लिकहाउसमा कम पटक लेख्नुपर्छ भन्ने सुझाव दिन्छ। यसले, बारीमा, बफर ओभरफ्लो र लगहरू गुमाउन सक्छ। समाधान Fluentd बफर बढाउनु हो, तर त्यसपछि मेमोरी खपत पनि बढ्नेछ।

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

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

Elasticsearch को बारेमा के हो?

Elasticsearch भारी वर्कलोडहरू ह्यान्डल गर्न जानिन्छ। एउटै परियोजनामा ​​प्रयास गरौं। अब लोड यस्तो देखिन्छ:

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

तल्लो रेखा: यो विकल्प जायज हुन सक्छ, तर मात्र यदि परियोजना ठूलो छ र यसको व्यवस्थापन केन्द्रीकृत लगिङ प्रणालीमा महत्त्वपूर्ण स्रोतहरू खर्च गर्न तयार छ।

त्यसपछि स्वाभाविक प्रश्न उठ्छ:

के लगहरू साँच्चै आवश्यक छ?

दृष्टिकोण आफै परिवर्तन गर्ने प्रयास गरौं: लगहरू एकै साथ जानकारीमूलक हुनुपर्छ र कभर हुँदैन हरेक प्रणाली मा घटना।

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

त्यसैले हामी यो निष्कर्षमा पुगेका छौं केन्द्रीकृत लगिङ सधैं उचित हुँदैन। प्रायः ग्राहकले सबै लगहरू एकै ठाउँमा सङ्कलन गर्न चाहन्छ, यद्यपि वास्तवमा, सम्पूर्ण लगबाट, केवल सशर्त 5% सन्देशहरू जुन व्यवसायका लागि महत्वपूर्ण छन्:

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

जीवनबाट चित्रण

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

कर्पोरेट समस्या पत्ता लगाउने सेन्सर - QRadar संग केन्द्रीकृत लग संग्रह प्रणाली को "साथी बनाउन" आवश्यक थियो। यो प्रणालीले syslog प्रोटोकल मार्फत लगहरू प्राप्त गर्न सक्छ र तिनीहरूलाई FTP बाट पुन: प्राप्त गर्न सक्छ। यद्यपि, यसलाई fluentd को लागि remote_syslog प्लगइनसँग एकीकृत गर्न तुरुन्तै सम्भव थिएन। (जस्तो भयो, हामी एक्लै छैनौं)। QRadar सेटअप गर्ने समस्याहरू ग्राहकको सुरक्षा टोलीको पक्षमा देखा पर्‍यो।

फलस्वरूप, व्यापार-महत्वपूर्ण लगहरूको भाग FTP QRadar मा अपलोड गरियो, र अर्को भाग नोडहरूबाट सीधा रिमोट syslog मार्फत रिडिरेक्ट गरियो। यसका लागि हामीले लेखेका पनि छौं सरल चार्ट - सायद यसले कसैलाई यस्तै समस्या समाधान गर्न मद्दत गर्नेछ... नतिजा योजनाको लागि धन्यवाद, ग्राहकले आफैंले महत्वपूर्ण लगहरू प्राप्त गर्यो र विश्लेषण गर्यो (उनको मनपर्ने उपकरणहरू प्रयोग गरेर), र हामीले लगिङ प्रणालीको लागत घटाउन सक्षम भयौं, केवल बचत अघिल्लो महिना।

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

लगहरूको लागि मापदण्ड

त्यस्ता उदाहरणहरूले निष्कर्षमा पुग्छ कि लग सङ्कलन प्रणाली छनौट गर्नुको अतिरिक्त, तपाइँलाई आवश्यक छ लगहरू पनि आफैं डिजाइन गर्नुहोस्! यहाँ के आवश्यकताहरू छन्?

• लगहरू मेसिन-पढ्ने ढाँचामा हुनुपर्छ (उदाहरणका लागि, 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 ले छोटो अवधिका कन्टेनरहरूबाट लगहरू सङ्कलन गर्न सक्दैन। हाम्रो एउटा परियोजनामा, डाटाबेस माइग्रेसन कन्टेनर ४ सेकेन्डभन्दा कम समयसम्म रह्यो र त्यसपछि मेटाइयो - सम्बन्धित एनोटेसन अनुसार:

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

यस कारणले, माइग्रेसन कार्यान्वयन लग भण्डारणमा समावेश गरिएको थिएन। यस अवस्थामा राजनीतिले मद्दत गर्न सक्छ। before-hook-creation.

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

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

अन्तमा, हामीले त्यो बिर्सनु हुँदैन कुनै पनि उपप्रणालीलाई राम्ररी अनुगमन गर्न महत्त्वपूर्ण छ। अन्यथा, यो एक अवस्था मा भाग्न सजिलो छ जसमा धाराप्रवाह एक राज्य मा छ CrashLoopBackOff र केहि पठाउँदैन, र यसले महत्त्वपूर्ण जानकारी गुमाउने प्रतिज्ञा गर्दछ।

निष्कर्ष

यस लेखमा, हामी Datadog जस्तै SaaS समाधानहरू हेरिरहेका छैनौं। यहाँ वर्णन गरिएका धेरै समस्याहरू पहिले नै लगहरू सङ्कलन गर्न विशेषज्ञ व्यावसायिक कम्पनीहरूले कुनै न कुनै रूपमा समाधान गरिसकेका छन्, तर सबैले विभिन्न कारणहरूले SaaS प्रयोग गर्न सक्दैनन्। (मुख्य भनेको लागत र 152-FZ को अनुपालन हो).

केन्द्रीकृत लग संग्रह सुरुमा एक साधारण कार्य जस्तो देखिन्छ, तर यो पटक्कै होइन। यो सम्झना महत्त्वपूर्ण छ कि:

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

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

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «लगहाउस प्रस्तुत गर्दै - Kubernetes मा लगहरूसँग काम गर्नको लागि खुला स्रोत प्रणाली»;
• «KubeCon'19 बाट Kubernetes इकोसिस्टमको लागि रिलीज: JFrog कन्टेनर रजिस्ट्री, IBM बाट Kui, Loki 1.0.0...»;
• «निगरानी र Kubernetes (समीक्षा र भिडियो रिपोर्ट)"।

स्रोत: www.habr.com