कंटेनर लॉग एग्रीगेशन कैसे काम करता है
कंटेनर लॉग एग्रीगेशन अल्पकालिक कंटेनरों से लॉग एकत्र करने और उन्हें एक एकल, केंद्रीकृत प्रणाली में व्यवस्थित करने की प्रक्रिया को सरल बनाता है।. यह प्रक्रिया अत्यंत महत्वपूर्ण है क्योंकि कंटेनरीकृत वातावरण में भारी मात्रा में लॉग डेटा उत्पन्न होता है, और कंटेनर अक्सर लॉग डेटा के साथ ही गायब हो जाते हैं। डेटा एकत्रीकरण के बिना, समस्या निवारण अप्रभावी और खंडित हो जाता है।.
आपको यह जानना आवश्यक है:
- कंटेनर फ़ाइलों में नहीं, बल्कि स्ट्रीम (STDOUT/STDERR) में लॉग करते हैं।. यदि लॉग को बाहरी सिस्टमों पर रूट नहीं किया जाता है, तो कंटेनर बंद होने पर लॉग गायब हो जाते हैं।.
- प्रबंधित कुबेरनेट्स यह नोड स्तर पर लॉग को केंद्रीकृत करता है।. कुबेलेट जैसे उपकरण लॉग रोटेशन को संभालते हैं, जबकि पथ जैसे
/var/log/pods/लॉग को अस्थायी रूप से संग्रहीत करें।. - संग्रह विधियों में नोड-स्तरीय एजेंट और साइडकार शामिल हैं।. नोड एजेंट (जैसे, फ्लुएंट बिट) क्लस्टर-व्यापी लॉग के लिए कुशल होते हैं, जबकि साइडकार कस्टम लॉग प्रारूप वाले ऐप्स के लिए काम करते हैं।.
- केंद्रीकृत भंडारण से डेटा की निरंतरता सुनिश्चित होती है।. लॉग को क्वेरी करने, विश्लेषण करने और दीर्घकालिक रूप से सुरक्षित रखने के लिए Elasticsearch या Loki जैसे प्लेटफार्मों पर भेजा जाता है।.
यह क्यों मायने रखती है: लॉग को केंद्रीकृत करने से संरचित खोज और रीयल-टाइम मॉनिटरिंग संभव हो पाती है, जिससे समस्या निवारण का समय कम हो जाता है। लॉग खोने से बचने के लिए, उन्हें हमेशा मानक स्ट्रीम में भेजें और भंडारण और परिवहन के लिए विश्वसनीय बुनियादी ढांचे का उपयोग करें।.
स्केलेबल सेटअप के लिए, नोड-स्तरीय एजेंटों को काफ्का या इलास्टिकसर्च जैसे मजबूत स्टोरेज बैकएंड के साथ संयोजित करें। इससे यह सुनिश्चित होता है कि लॉग उच्च मात्रा वाले वातावरण में भी सुलभ और व्यवस्थित रहें।.
कंटेनर लॉग एग्रीगेशन पाइपलाइन: उत्पादन से लेकर भंडारण तक
Kubernetes लॉग एग्रीगेशन: क्लस्टर-व्यापी लॉग एकत्र करना | संपूर्ण गाइड
एसबीबी-आईटीबी-59e1987
कंटेनर लॉग कैसे उत्पन्न करते हैं
कंटेनर लॉग को स्टैटिक फ़ाइलों के रूप में सहेजने के बजाय स्ट्रीम का उपयोग करके उत्पन्न करते हैं। कंटेनर के भीतर प्रत्येक प्रक्रिया यूनिक्स से प्राप्त तीन I/O स्ट्रीम का उपयोग करती है: एसटीडीआईएन (स्ट्रीम 0) इनपुट के लिए, STDOUT (स्ट्रीम 1) मानक आउटपुट के लिए, और एसटीडीईआरआर त्रुटि संदेशों के लिए (स्ट्रीम 2)।.
जब आपका एप्लिकेशन चलता है, तो यह परिचालन डेटा और स्थिति अपडेट भेजता है। STDOUT, जबकि त्रुटियाँ, चेतावनियाँ और नैदानिक संदेश निम्नलिखित को निर्देशित किए जाते हैं एसटीडीईआरआर. कंटेनर रनटाइम – चाहे वह डॉकर हो, कंटेनरडी हो, या कोई अन्य सीआरआई-अनुरूप टूल हो – कंटेनरीकृत प्रक्रिया से सीधे इन स्ट्रीम को कैप्चर करता है। यह पाइप के माध्यम से प्राप्त किया जाता है जो कंटेनर के पृथक वातावरण से आउटपुट को पुनर्निर्देशित करते हैं। वर्चुअल प्राइवेट सर्वर का होस्ट फ़ाइल सिस्टम।.
""कंटेनरीकृत अनुप्रयोगों के लिए सबसे आसान और सबसे अधिक अपनाया जाने वाला लॉगिंग तरीका मानक आउटपुट और मानक त्रुटि स्ट्रीम में लिखना है।" – कुबेरनेट्स प्रलेखन
कंटेनर की राइटेबल लेयर में लॉग्स को सेव न करना महत्वपूर्ण है। एक बार कंटेनर बंद हो जाए या हटा दिया जाए, तो उसके अंदर मौजूद सब कुछ – लॉग फाइलों सहित – गायब हो जाता है। लॉग्स के नुकसान से बचने के लिए, एप्लिकेशन को सभी लॉगिंग को रूट करना होगा। STDOUT तथा एसटीडीईआरआर. पुराने एप्लिकेशन जो लॉग को फ़ाइलों में लिखते हैं, उनके लिए आप सिंबॉलिक लिंक बना सकते हैं। /देव/स्टडआउट या /देव/स्टडेर.
अब आइए जानें कि इन आउटपुट स्ट्रीम को कैसे कैप्चर और मैनेज किया जाता है।.
कंटेनर लॉग आउटपुट स्ट्रीम
कंटेनर रनटाइम केवल लॉग कैप्चर करने से कहीं अधिक कार्य करते हैं - वे उन्हें फॉर्मेट और मैनेज भी करते हैं। जब डॉकर या कंटेनरडी को डेटा प्राप्त होता है STDOUT या एसटीडीईआरआर, एक घटक जिसे कहा जाता है परत यह प्रक्रिया करता है। शिम आउटपुट को पढ़ता है, मेटाडेटा जोड़ता है और इसे होस्ट लॉग फ़ाइलों में लिखता है। यह सेटअप सुनिश्चित करता है कि लॉग डेटा सुरक्षित रहे, भले ही कंटेनर का जीवनकाल छोटा हो।.
डॉकर उपयोग करता है लॉगिंग ड्राइवर यह निर्धारित करने के लिए कि लॉग कैसे और कहाँ संग्रहीत किए जाते हैं। डिफ़ॉल्ट JSON फ़ाइल ड्राइवर लॉग फ़ाइलों को होस्ट की डिस्क पर JSON फॉर्मेट में सेव करता है। प्रत्येक लॉग एंट्री में टाइमस्टैम्प, सोर्स स्ट्रीम (stdout या stderr) और लॉग मैसेज शामिल होते हैं। अधिक मात्रा में आउटपुट के दौरान परफॉर्मेंस संबंधी समस्याओं से बचने के लिए, डॉकर नॉन-ब्लॉकिंग मोड प्रदान करता है। यह मोड प्रत्येक कंटेनर के लिए 1MB बफर का उपयोग करता है ताकि आउटपुट रुकने से बचा जा सके, हालांकि इसका मतलब यह है कि बफर भर जाने पर कुछ मैसेज छूट सकते हैं।.
| धारा का नाम | फ़ाइल विवरणक | उद्देश्य |
|---|---|---|
| एसटीडीआईएन | 0 | इनपुट |
| STDOUT | 1 | मानक आउटपुट |
| एसटीडीईआरआर | 2 | त्रुटि संदेश |
अंतर को समझना STDOUT तथा एसटीडीईआरआर फ़िल्टरिंग और अलर्टिंग के लिए यह महत्वपूर्ण है। एसटीडीईआरआर यह आमतौर पर त्रुटियों या चेतावनियों को उजागर करता है, निगरानी उपकरणों को इस स्ट्रीम के आधार पर अलर्ट भेजने के लिए कॉन्फ़िगर किया जा सकता है, जबकि उनका उपचार किया जाता है। STDOUT सूचनात्मक उद्देश्यों के लिए। हालांकि, बैकप्रेशर के कारण इन स्ट्रीम्स के अवरुद्ध होने पर एप्लिकेशन में समस्याएं आ सकती हैं। डॉकर का नॉन-ब्लॉकिंग मोड इस समस्या को कम करता है, हालांकि इसके बदले में नए लॉग संदेशों के खोने की संभावना रहती है।.
जबकि कंटेनर रनटाइम लॉगिंग की बुनियादी बातों को संभालते हैं, कुबेरनेट्स नोड-स्तरीय प्रबंधन नीतियों के साथ इसे एक कदम आगे ले जाता है।.
कुबेरनेट्स लॉग प्रबंधन
Kubernetes में, कुबेलेट यह लॉग प्रबंधन की जिम्मेदारी लेता है। यह निर्धारित करता है कि प्रत्येक नोड पर लॉग कहाँ संग्रहीत किए जाते हैं और डिस्क स्थान समाप्त होने से बचाने के लिए रोटेशन नीतियों को लागू करता है। डिफ़ॉल्ट रूप से, Kubernetes कंटेनर लॉग को निम्न पथ में सहेजता है:
/var/log/pods/{namespace}_{pod-name}_{pod-uid}/{container-name}/{restart-count}.log.
इसके अतिरिक्त, यह निम्नलिखित स्थानों पर प्रतीकात्मक संबंध बनाता है: /var/log/कंटेनर/ मनुष्यों और लॉग संग्रह उपकरणों द्वारा आसान पहुंच के लिए।.
Kubernetes लॉग फ़ाइलों का आकार 10MiB तक पहुँचने पर उन्हें रोटेट करता है, और प्रति कंटेनर अधिकतम पाँच रोटेशन तक रखता है। उदाहरण के लिए, तीन कंटेनर वाले एक पॉड में लॉग फ़ाइलों के तीन अलग-अलग सेट होंगे। जब आप इसे चलाते हैं kubectl लॉग, कुबेलेट इन फाइलों को सीधे नोड के स्टोरेज से प्राप्त करता है।.
""शिम निम्नलिखित कार्यों के लिए ज़िम्मेदार है: कंटेनर प्रक्रियाओं से stdout/stderr आउटपुट पढ़ना… लॉग फ़ाइलों को फ़ॉर्मेट करना… सीधे लॉग फ़ाइलों में लिखना।" – एडो झांग, सीएनसीएफ एंबेसडर
कुबेलेट और कंटेनर रनटाइम के बीच एकीकरण कंटेनर रनटाइम इंटरफ़ेस (CRI) लॉगिंग प्रारूप का पालन करता है। यह मानक सुनिश्चित करता है कि Kubernetes लॉग को लगातार संभाले, चाहे कोई भी रनटाइम उपयोग में हो – चाहे वह Docker, Containerd, CRI-O, या कोई अन्य विकल्प हो। Kubernetes v1.32 से, एक नया अल्फा फ़ीचर जोड़ा गया है जिसे पॉडलॉग्सक्वेरीस्प्लिटस्ट्रीम आपको क्वेरी करने की अनुमति देता है STDOUT तथा एसटीडीईआरआर पॉड एपीआई के माध्यम से लॉग स्ट्रीम को अलग-अलग स्ट्रीम करें। इससे आपको यह तय करने में अधिक नियंत्रण मिलता है कि आप किन लॉग स्ट्रीम तक पहुंचना चाहते हैं।.
ये तंत्र यह सुनिश्चित करते हैं कि कुबेरनेट्स केंद्रीकृत प्रणालियों को संरचित, विश्वसनीय लॉग डेटा प्रदान कर सके।.
लॉग संग्रह विधियाँ
जब कंटेनर किसी नोड के फ़ाइल सिस्टम में लॉग लिखते हैं, तो आपको अपने क्लस्टर में उन्हें एकत्रित करने के लिए एक विश्वसनीय तरीके की आवश्यकता होती है। इसके लिए दो मुख्य तरीके हैं: नोड-स्तरीय एजेंट कुशल, क्लस्टर-व्यापी लॉग हैंडलिंग के लिए, और साइडकार कंटेनर विशिष्ट अनुप्रयोगों की आवश्यकताओं के लिए। प्रत्येक विधि आपके सेटअप और आवश्यकताओं के आधार पर अलग-अलग लाभ प्रदान करती है।.
नोड-स्तरीय लॉगिंग एजेंट
नोड-स्तरीय लॉगिंग एजेंटों का उपयोग करने में Kubernetes के माध्यम से प्रत्येक नोड पर एक लॉगिंग टूल को तैनात करना शामिल है। डेमनसेट. इससे यह सुनिश्चित होता है कि प्रत्येक वर्कर नोड पर एक एजेंट पॉड (जो Fluentd या Fluent Bit जैसे टूल चलाता है) काम करता है। ये एजेंट डायरेक्टरी को माउंट करते हैं। /var/log/pods या /var/log/कंटेनर, होस्ट पर संग्रहीत कंटेनर लॉग तक सीधी पहुंच प्राप्त करना।.
""नोड स्तर का एजेंट, जैसे कि Fluentd डेमनसेट। यही अनुशंसित पैटर्न है।" – AWS नेटिव ऑब्जर्वेबिलिटी गाइड
यह एजेंट लगातार लॉग फाइलों की निगरानी करता है और उन्हें कुबेरनेट्स मेटाडेटा (जैसे, पॉड नाम, नेमस्पेस, कंटेनर नाम और लेबल) से समृद्ध करता है ताकि इलास्टिकसर्च या ओपनसर्च जैसे केंद्रीकृत स्टोरेज सिस्टम में लॉग को खोजना आसान हो जाए।. धाराप्रवाह बिट अपने हल्के डिजाइन और न्यूनतम संसाधन खपत के कारण यह इस भूमिका के लिए एक लोकप्रिय विकल्प है।.
प्रदर्शन को बेहतर बनाने के लिए, एजेंट को इस प्रकार कॉन्फ़िगर करें: स्रोत पर ही लॉग को फ़िल्टर करें. नोड स्तर पर अनावश्यक लॉग को हटाने से नेटवर्क ट्रैफ़िक और स्टोरेज लागत दोनों कम हो जाती हैं। मेमोरी बफ़र सीमाएँ निर्धारित करें (उदाहरण के लिए, मेमोरी_बफर_सीमा लॉग स्पाइक्स या बैकएंड आउटेज के दौरान अत्यधिक मेमोरी उपयोग को रोकने के लिए (फ्लुएंट बिट में)। बड़े क्लस्टर के लिए, एजेंटों को कुबेलेट से स्थानीय रूप से मेटाडेटा प्राप्त करने के लिए कॉन्फ़िगर करें।Use_KubeletKubernetes API सर्वर से क्वेरी करने के बजाय, जिससे API दर सीमाओं से बचने में मदद मिलती है।.
| विशेषता | नोड-स्तरीय एजेंट (डेमनसेट) | साइडकार कंटेनर |
|---|---|---|
| स्रोत का उपयोग | कम (प्रति नोड एक एजेंट) | उच्च (प्रति पॉड एक एजेंट) |
| ऐप संशोधन | कोई आवश्यकता नहीं | पॉड स्पेसिफिकेशन में बदलाव की आवश्यकता है |
| अनुमापकता | उच्च | मध्यम (पॉड के आकार में वृद्धि करता है) |
| सर्वोत्तम उपयोग मामला | क्लस्टर-व्यापी लॉग प्रबंधन | कस्टम लॉग फॉर्मेट वाले ऐप्स |
kubectl लॉग समर्थन | पूरी तरह से समर्थित | एजेंट द्वारा संभाले जाने वाले लॉग के लिए समर्थित नहीं है |
यह विधि व्यक्तिगत अनुप्रयोगों को संशोधित किए बिना आपके क्लस्टर में लॉग एकत्र करने का एक स्केलेबल और कुशल तरीका प्रदान करती है।.
लकड़ी संग्रहण के लिए साइडकार कंटेनर
साइडकार कंटेनर अधिक अनुकूलित दृष्टिकोण प्रदान करते हैं, खासकर जब एप्लिकेशन सीधे फाइलों में लॉग करते हैं। साइडकार कंटेनर यह मुख्य एप्लिकेशन कंटेनर के साथ-साथ उसी पॉड में चलता है, स्टोरेज और नेटवर्क नेमस्पेस साझा करता है। यह सेटअप उन एप्लिकेशन के लिए आदर्श है जो लॉग को फ़ाइलों में लिखते हैं। STDOUT या एसटीडीईआरआर, विशेषकर जावा मल्टी-लाइन लॉग जैसे जटिल प्रारूपों से निपटने के दौरान, जिन्हें नोड-स्तरीय एजेंटों को संसाधित करने में कठिनाई हो सकती है।.
""साइडकार/एजेंट मॉडल तब उपयोगी होता है जब कंटेनर लॉग से लॉग प्रोसेसिंग करना किसी एप्लिकेशन से सीधे पढ़ने जितना कुशल साबित न हो (उदाहरण के लिए, जावा मल्टी-लाइन प्रोसेसिंग)।" - अनुराग गुप्ता, फ्लुएंट बिट
इस मॉडल में, एप्लिकेशन लॉग को एक साझा वॉल्यूम (आमतौर पर Kubernetes) में लिखता है। खाली निर्देशिका), और साइडकार कंटेनर इन लॉग्स को ट्रैक करता है और उन्हें एक केंद्रीकृत बैकएंड पर भेजता है। Fluentd, Fluent Bit और Filebeat जैसे टूल्स आमतौर पर साइडकार के रूप में उपयोग किए जाते हैं। Kubernetes v1.29 से शुरू होकर, नेटिव साइडकार सपोर्ट आपको साइडकार को रीस्टार्ट करने योग्य इनिट कंटेनर के रूप में परिभाषित करने की अनुमति देता है। रीस्टार्टपॉलिसी: हमेशा, यह सुनिश्चित करते हुए कि वे मुख्य कंटेनर से पहले शुरू हों और उसके समाप्त होने के बाद ही रुकें।.
साइडकार सटीक लॉग हैंडलिंग की अनुमति देते हैं, लेकिन इनमें संसाधनों की लागत अधिक होती है। प्रत्येक पॉड अपना स्वयं का लॉगिंग एजेंट चलाता है, जिससे स्टोरेज की आवश्यकता दोगुनी हो सकती है यदि साइडकार लॉग को स्ट्रीम करता है। STDOUT. ओवरहेड को कम करने के लिए, साइडकार का उपयोग केवल उन अनुप्रयोगों के लिए करें जो सीधे मानक स्ट्रीम में लॉग नहीं कर सकते हैं, और यह सुनिश्चित करें कि साइडकार कंटेनर जितना संभव हो उतना हल्का हो।.
लॉग्स का केंद्रीकरण और परिवहन
लॉग जनरेशन और कलेक्शन के बाद, आइए समझते हैं कि लॉग को कैसे केंद्रीकृत और स्थानांतरित किया जाता है। एक बार एकत्र हो जाने के बाद, लॉग को एक विश्वसनीय रिपॉजिटरी में संग्रहीत करना आवश्यक है जो पॉड रीस्टार्ट और नोड विफलताओं को सहन कर सके। इस प्रक्रिया में अक्सर अचानक ट्रैफ़िक बढ़ने पर उसे संभालने के लिए बफ़रिंग लेयर और त्वरित क्वेरी के लिए डिज़ाइन किए गए रिमोट स्टोरेज सिस्टम का उपयोग शामिल होता है। नीचे, हम जानेंगे कि कुशल पहुँच के लिए लॉग को कैसे स्थानांतरित और व्यवस्थित किया जाता है।.
लॉग परिवहन के लिए संदेश दलाल
किसी मैसेज ब्रोकर का उपयोग करना जैसे अपाचे काफ्का लॉग ट्रांसपोर्ट को संभालने का एक सामान्य तरीका है। काफ्का लॉगिंग एजेंटों और स्टोरेज के बीच एक बफर के रूप में काम करता है, जिससे यह सुनिश्चित होता है कि ट्रैफिक बढ़ने पर भी लॉग खो न जाएं। लॉग प्रोड्यूसर और कंज्यूमर को अलग करके, काफ्का एजेंटों को तब भी लॉग लिखने की अनुमति देता है जब स्टोरेज सिस्टम अस्थायी रूप से अनुपलब्ध या ओवरलोड हो। यह सेटअप लॉग को सुरक्षित रूप से कतार में रखता है जब तक कि स्टोरेज सिस्टम उन्हें प्रोसेस करने के लिए तैयार न हो जाए।.
सरल सेटअप के लिए, रेडिस यह एक हल्के क्यू के रूप में काम कर सकता है, हालांकि यह काफ्का द्वारा प्रदान की जाने वाली मजबूती प्रदान नहीं करता है। AWS वातावरण में, किनेसिस डेटा फायरहोज Kafka एक पसंदीदा प्रबंधित सेवा है जो लॉग वॉल्यूम के साथ स्वचालित रूप से स्केल होती है। Kafka सेटअप करते समय, विभाजन की गणना सावधानीपूर्वक करना महत्वपूर्ण है - कुल थ्रूपुट को प्रोड्यूसर या कंज्यूमर की निम्न दर से विभाजित करें, और प्रदर्शन बनाए रखने के लिए प्रति ब्रोकर 4,000 से कम विभाजन रखें।.
लॉग संग्रहण संगठन
लॉग को कैसे स्टोर किया जाता है, यह काफी हद तक उपयोग में आने वाले स्टोरेज सिस्टम पर निर्भर करता है। जैसे टूल्स Elasticsearch तथा ओपनसर्च लॉग को समय-आधारित सूचकांकों में व्यवस्थित करें (उदाहरण के लिए, लॉगस्टैश-2026.02.16), जिससे हालिया डेटा को क्वेरी करना तेज़ हो जाता है। दूसरी ओर, ग्राफ़ाना लोकी यह केवल मेटाडेटा (जैसे नेमस्पेस, पॉड नाम और कंटेनर नाम) को इंडेक्स करके और लॉग सामग्री को संपीड़ित ऑब्जेक्ट स्टोरेज में संग्रहीत करके अधिक लागत-कुशल विधि का उपयोग करता है।.
लॉग को लंबे समय तक सुरक्षित रखने के लिए, अक्सर स्तरीय भंडारण प्रणाली का उपयोग किया जाता है:
- हॉट टियरलॉग्स को उच्च-प्रदर्शन वाले एसएसडी पर 30-90 दिनों के लिए संग्रहीत किया जाता है, जो सक्रिय समस्या निवारण के लिए आदर्श है।.
- गर्म स्तरलॉग फ़ाइलों को ऐतिहासिक विश्लेषण के लिए धीमी डिस्क पर स्थानांतरित किया जाता है, जिन्हें आमतौर पर 90 दिनों से लेकर एक वर्ष तक रखा जाता है।.
- शीत स्तरएक वर्ष से पुराने लॉग को अनुपालन या ऑडिटिंग उद्देश्यों के लिए AWS S3 जैसे ऑब्जेक्ट स्टोरेज में संग्रहीत किया जाता है।.
जब लॉग ऑब्जेक्ट स्टोरेज में संग्रहीत होते हैं, तो उन्हें अक्सर तिथि और सेवा नाम के आधार पर विभाजित किया जाता है। यह संरचना अमेज़ॅन एथेना जैसे टूल के लिए क्वेरी को अनुकूलित करने में मदद करती है, जिससे आवश्यकता पड़ने पर विशिष्ट लॉग को आसानी से प्राप्त किया जा सकता है।.
लॉग का विश्लेषण और उन तक पहुंच
एक बार लॉग केंद्रीकृत हो जाने के बाद, आप इसका उपयोग कर सकते हैं। CLI उपकरण त्वरित समस्या निवारण के लिए या भरोसा करने के लिए केंद्रीकृत बैकएंड गहन विश्लेषण के लिए। जैसे उपकरण kubectl लॉग तथा डॉकर लॉग ये उपकरण तत्काल पहुंच के लिए एकदम सही हैं, क्योंकि ये कंटेनर रनटाइम या कुबेलेट के साथ संचार करके सीधे स्थानीय लॉग फ़ाइलों को पढ़ते हैं। इन उपकरणों को किसी केंद्रीकृत बैकएंड की आवश्यकता नहीं होती है, जिससे ये वास्तविक समय की जांच के लिए सुविधाजनक बन जाते हैं।.
अधिक उन्नत विश्लेषण के लिए, लॉग को Elasticsearch, OpenSearch या Grafana Loki जैसे प्लेटफ़ॉर्म पर भेजा जाता है। प्रत्येक सिस्टम डेटा को अलग-अलग तरीके से संभालता है: Elasticsearch समय-आधारित इंडेक्स का उपयोग करता है (उदाहरण के लिए, लॉगस्टैश-2026.02.16Kubernetes (Kubernetes) पूर्ण-पाठ खोज के लिए एक टूल है, जबकि Loki पॉड नाम, नेमस्पेस और लेबल जैसे मेटाडेटा को इंडेक्स करने पर ध्यान केंद्रित करता है और वास्तविक लॉग सामग्री को संपीड़ित ऑब्जेक्ट स्टोरेज में संग्रहीत करता है। यह दृष्टिकोण Loki को बड़े पैमाने पर तैनाती के लिए एक लागत-प्रभावी विकल्प बनाता है। जैसा कि Kubernetes दस्तावेज़ीकरण में बताया गया है, ""एक क्लस्टर में, लॉग का एक अलग स्टोरेज होना चाहिए और नोड्स, पॉड्स या कंटेनरों से स्वतंत्र एक जीवनचक्र होना चाहिए। इस अवधारणा को क्लस्टर-स्तरीय लॉगिंग कहा जाता है।""
लॉग की जाँच करते समय, निम्नलिखित जैसे टूल का उपयोग किया जा सकता है: KQL (किबाना क्वेरी भाषा) या SQL-आधारित सिंटैक्स का आमतौर पर उपयोग किया जाता है। उदाहरण के लिए, किसी विशिष्ट नेमस्पेस में त्रुटियों की खोज कुछ इस तरह दिख सकती है: लॉग.स्तर: "त्रुटि" और कुबेरनेट्स.नेमस्पेस: "उत्पादन"". कमांड लाइन पर, kubectl लॉग लेबल जैसे फ़िल्टरिंग विकल्प प्रदान करता है (-l ऐप=एनजीइनक्स), समय सीमा (--since=1h), और यहां तक कि क्रैश हुए कंटेनरों से लॉग प्राप्त करना भी संभव है। --पहले का फ्लैग। हालांकि CLI उपकरण तात्कालिक जरूरतों के लिए बेहतरीन हैं, लेकिन केंद्रीकृत प्रणालियाँ ऐतिहासिक और प्रवृत्ति विश्लेषण के लिए व्यापक दृष्टिकोण प्रदान करती हैं।.
लॉग क्वेरी के लिए CLI उपकरण
त्वरित जानकारी प्राप्त करने के लिए कमांड-लाइन उपकरण अपरिहार्य हैं, विशेष रूप से जब लॉग को केंद्रीय रूप से एकत्रित किया जाता है। kubectl लॉग यह कमांड व्यापक रूप से उपयोग की जाती है, लेकिन इसकी कुछ सीमाएँ हैं। उदाहरण के लिए, Kubernetes kubelet लॉग को तब रोटेट करता है जब वे एक निश्चित सीमा तक पहुँच जाते हैं। 10 मील और केवल रखता है 5 फ़ाइलें प्रति कंटेनर। इसका मतलब है कि यदि कोई पॉड 40 मील लॉग उत्पन्न करता है, तो आप केवल सबसे हाल के 10 मील ही देख पाएंगे। kubectl लॉग. सिस्टम-स्तर की समस्याओं के लिए, लिनक्स नोड्स चल रहे हैं। systemd यह आपको कुबेलेट और कंटेनर रनटाइम लॉग को क्वेरी करने की अनुमति देता है। journalctl आज्ञा।.
यहां कुछ उपयोगी जानकारी दी गई है kubectl लॉग झंडे:
--तब से: यह किसी विशिष्ट समयावधि, जैसे कि पिछले एक घंटे, के लॉग्स को पुनः प्राप्त करता है।--since=1h).--पूँछ: आउटपुट को अंतिम कुछ पंक्तियों तक सीमित करता है, उदाहरण के लिए, सबसे हाल की 20 पंक्तियाँ (--टेल=20).--टाइमस्टैम्प: प्रत्येक लॉग लाइन में टाइमस्टैम्प जोड़ता है, जिससे समय संबंधी समस्याओं का विश्लेषण करना आसान हो जाता है।.
एकत्रीकरण मोड तुलना
स्थानीय लॉग रोटेशन और केंद्रीकृत एकत्रीकरण के बीच के अंतर को समझना सही दृष्टिकोण चुनने की कुंजी है। क्यूबलेट द्वारा प्रबंधित स्थानीय रोटेशन, लॉग को नोड की डिस्क पर संग्रहीत करता है। /var/log/pods. हालांकि, पॉड के हटाए जाने या नोड के विफल होने पर ये लॉग नष्ट हो जाते हैं। दूसरी ओर, केंद्रीकृत एकत्रीकरण, लॉग को इलास्टिकसर्च या क्लाउड स्टोरेज जैसे बाहरी सिस्टम में संग्रहीत करता है, जिससे यह सुनिश्चित होता है कि कंटेनर समाप्त होने के बाद भी लॉग सुलभ बने रहें।.
| विशेषता | डिफ़ॉल्ट (स्थानीय) रोटेशन | केंद्रीकृत एकत्रीकरण |
|---|---|---|
| रखने की जगह | स्थानीय नोड डिस्क (/var/log/pods) | बाह्य बैकएंड (जैसे, इलास्टिकसर्च, क्लाउड स्टोरेज) |
| अटलता | रोटेशन या पॉड इविक्शन के बाद लॉग हटा दिए जाते हैं | पॉड और नोड के जीवनचक्र से परे बरकरार रखा गया |
| सरल उपयोग | के माध्यम से पहुंचें kubectl लॉग (केवल नवीनतम फ़ाइल) | वेब यूआई या एपीआई के माध्यम से पहुंच (संपूर्ण इतिहास) |
| खोज क्षमता | बुनियादी टेक्स्ट स्ट्रीमिंग/टेलिंग | उन्नत क्वेरी, इंडेक्सिंग और सहसंबंध |
| संसाधन प्रभाव | न्यूनतम (क्यूबेलेट द्वारा नियंत्रित) | उच्चतर (एजेंट और नेटवर्क बैंडविड्थ की आवश्यकता होती है) |
केंद्रीकृत लॉगिंग प्लेटफॉर्म मूल कारण विश्लेषण में लगने वाले समय को काफी हद तक कम कर सकते हैं - लगभग 80%, उद्योग के आंकड़ों के अनुसार, यह दक्षता उन्नत क्वेरी क्षमताओं, मल्टी-सर्विस लॉग सहसंबंध और ऐतिहासिक डेटा प्रतिधारण जैसी सुविधाओं से प्राप्त होती है। उच्च लॉग मात्रा वाले वातावरणों के लिए, संग्रहण चरण में लॉग सैंपलिंग लागू करने से सिस्टम प्रदर्शन की महत्वपूर्ण जानकारी बनाए रखते हुए भंडारण लागत को नियंत्रित करने में मदद मिल सकती है। डेटा को स्थायी रूप से संग्रहीत करने और क्वेरी क्षमता के बीच यह संतुलन प्रभावी लॉग प्रबंधन के लिए महत्वपूर्ण है।.
कैसे Serverion लॉग एग्रीगेशन का समर्थन करता है
एक बार जब आप लॉग संग्रह और संग्रहण रणनीतियाँ स्थापित कर लेते हैं, तो अगला कदम लॉग की अखंडता बनाए रखने के लिए सही बुनियादी ढांचा तैयार करना होता है - और यहीं पर सर्वरियन अपनी उत्कृष्टता दिखाता है। प्रभावी लॉग एकत्रीकरण के लिए दोनों की आवश्यकता होती है। स्थायी भंडारण तथा उच्च-प्रदर्शन अवसंरचना, Serverion के VPS और डेडिकेटेड सर्वर इसी सुविधा को प्रदान करने के लिए बनाए गए हैं। कंटेनर स्वभाव से अस्थायी होते हैं, इसलिए जब कंटेनर बंद होता है तो उनके लॉग गायब हो जाते हैं, जब तक कि उन्हें सुरक्षित रखने के लिए कोई स्थिर होस्ट स्टोरेज न हो। कंटेनर के पूरे जीवनचक्र में लॉग को सुरक्षित रखने के लिए स्थायी स्टोरेज आवश्यक है, खासकर पॉड विफलताओं या रीस्टार्ट की स्थिति में। Serverion इस समस्या का समाधान डेडिकेटेड स्टोरेज प्रदान करके करता है, जिसे 250 μm पर माउंट किया जाता है। /var/लॉग/, यह सुनिश्चित करता है कि आपके लॉग कंटेनर रीस्टार्ट, पॉड इविक्शन और यहां तक कि नोड विफलताओं से भी सुरक्षित रहें।.
समर्पित सर्वर लॉग एग्रीगेशन वर्कलोड को संभालने में बेयर मेटल सर्वर सबसे अलग हैं। वर्चुअलाइज़्ड वातावरणों के विपरीत, बेयर मेटल सर्वर हाइपरवाइज़र लेयर को हटा देते हैं, जिससे वे संसाधन-भारी लॉगिंग कार्यों और बड़ी मात्रा में टेलीमेट्री डेटा को संसाधित करने के लिए आदर्श बन जाते हैं। यह विशेष रूप से वितरित कंटेनर सेटअप में महत्वपूर्ण है जहां लॉग वॉल्यूम तेजी से बढ़ सकते हैं। इसके अलावा, नोड-स्तरीय लॉगिंग एजेंट का उपयोग करना - जहां एक एजेंट होस्ट पर सभी कंटेनरों से लॉग एकत्र करता है - साइडकार-आधारित लॉगिंग विधियों की तुलना में CPU और मेमोरी पर दबाव कम करता है।.
सर्वरियन वैश्विक डेटा केंद्र लॉग एग्रीगेशन में दक्षता की एक और परत जोड़ें। ये लॉग को उनके स्रोत के करीब प्रोसेस या स्टोर करने की अनुमति देते हैं, जिससे नेटवर्क लेटेंसी कम होती है और रीयल-टाइम मॉनिटरिंग बेहतर होती है। यह वितरित दृष्टिकोण ऑडिट लॉग को विशिष्ट अधिकार क्षेत्र में रखकर GDPR या HIPAA जैसे क्षेत्रीय नियमों का पालन करने में भी मदद करता है। अधिक ट्रैफ़िक वाले एप्लिकेशन के लिए, Serverion नॉन-ब्लॉकिंग लॉग डिलीवरी का समर्थन करता है, जहाँ प्रोसेसिंग से पहले लॉग को मेमोरी में बफ़र किया जाता है (आमतौर पर डिफ़ॉल्ट रूप से 1 MB तक)। यह लॉगिंग ऑपरेशन को आपके एप्लिकेशन को धीमा करने से रोकता है, साथ ही परफॉर्मेंस और कंप्लायंस को ऑप्टिमाइज़ करता है।.
सर्वरियन के इंफ्रास्ट्रक्चर का एक और महत्वपूर्ण लाभ यह है कि यह संसाधनों की कमी से बचाता है। फाइलबीट या फ्लुएंटडी जैसे लॉगिंग एजेंट लगातार I/O और नेटवर्क बैंडविड्थ पर निर्भर करते हैं, खासकर लॉगिंग में अचानक वृद्धि के दौरान। समर्पित संसाधनों के साथ, लॉगिंग पाइपलाइन आपके प्रोडक्शन वर्कलोड के साथ सिस्टम संसाधनों के लिए प्रतिस्पर्धा किए बिना रीयल-टाइम इंडेक्सिंग और सर्च को संभाल सकती है।.
लॉग एकत्रीकरण के प्रयासों को केंद्रीकृत करने वाले संगठनों के लिए, सर्वरियन का बुनियादी ढांचा सब कुछ कवर करता है: प्रत्येक कुबेरनेट्स नोड पर लॉग एकत्र करने के लिए डेमनसेट तैनात करने से लेकर मानक 10 MiB रोटेशन सीमा से परे ऐतिहासिक डेटा को बनाए रखने वाले स्टोरेज बैकएंड को होस्ट करने तक। स्थायी स्टोरेज, प्रोसेसिंग क्षमता और वैश्विक उपलब्धता का यह संयोजन स्केलेबल लॉग एकत्रीकरण सुनिश्चित करता है। सर्वरियन के साथ, आपके लॉग सुलभ और विश्वसनीय बने रहते हैं, चाहे व्यक्तिगत कंटेनर, पॉड या नोड के साथ कुछ भी हो जाए।.
निष्कर्ष
कंटेनरीकृत वातावरण में, लॉग एग्रीगेशन आवश्यक है दृश्यता बनाए रखने और सुचारू संचालन सुनिश्चित करने के लिए। कंटेनर, डिज़ाइन के अनुसार, अस्थायी होते हैं। जब वे रुकते हैं या क्रैश होते हैं, तो उनके लॉग भी गायब हो जाते हैं। एक केंद्रीकृत एकत्रीकरण प्रणाली के बिना, आपके पास नोड्स में बिखरे हुए डेटा साइलो रह जाते हैं, जिससे वितरित अनुप्रयोगों में समस्याओं का निदान करना लगभग असंभव हो जाता है। जैसा कि क्रोनोस्फीयर के उत्पाद विपणन प्रबंधक कार्ल कलाश बताते हैं: "लॉग एकत्रीकरण अवलोकनशीलता और सुरक्षा का एक मूलभूत पहलू है। लॉग को समेकित करके, आप अपने सिस्टम, एप्लिकेशन और बुनियादी ढांचे के व्यवहार और प्रदर्शन में पूर्ण दृश्यता प्राप्त करते हैं।"
केंद्रीकृत लॉगिंग पाइपलाइनें केवल सुविधा के लिए ही नहीं हैं, बल्कि ये क्रांतिकारी बदलाव लाती हैं। वास्तविक SaaS परिनियोजन दर्शाते हैं कि इनसे घटना समाधान का औसत समय 4 घंटे से घटकर 40 मिनट से भी कम हो सकता है। इस तरह का सुधार एक छोटी सी समस्या और एक बड़े व्यवधान के बीच का अंतर साबित हो सकता है।.
इसे प्रभावी ढंग से काम करने के लिए, लॉग को इवेंट स्ट्रीम के रूप में मानें और उन सभी को रूट करें। STDOUT तथा एसटीडीईआरआर. लॉग डेटा की अधिक मात्रा को कुशलतापूर्वक संभालने के लिए नोड-स्तरीय एजेंट तैनात करें और डिस्क की क्षमता को बनाए रखने के लिए उचित लॉग रोटेशन का उपयोग करें। सबसे महत्वपूर्ण बात यह है कि सुनिश्चित करें कि आपके लॉग का जीवनचक्र उन्हें उत्पन्न करने वाले कंटेनरों से स्वतंत्र हो। यह सेटअप नोड्स में मैन्युअल खोज की आवश्यकता को समाप्त करता है और साथ ही त्वरित समस्या निवारण के लिए स्वचालित अलर्ट और क्रॉस-टियर सहसंबंधों को सक्षम बनाता है।.
कंटेनरीकृत वर्कलोड चलाने वाले संगठनों के लिए, आपकी लॉगिंग रणनीति का समर्थन करने वाला बुनियादी ढांचा उतना ही महत्वपूर्ण है। विश्वसनीय समाधान, जैसे कि सर्वरियन के VPS और समर्पित सर्वर, लॉग इनपुट और डेटा रिटेंशन की मांगों को पूरा करने के लिए आवश्यक स्टोरेज क्षमता, प्रोसेसिंग पावर और वैश्विक डेटा सेंटर कनेक्टिविटी प्रदान करें। चाहे आप एक छोटा सेटअप संभाल रहे हों या सैकड़ों नोड्स, भरोसेमंद इंफ्रास्ट्रक्चर यह सुनिश्चित करता है कि आपके लॉग हमेशा सुलभ रहें और आपके मॉनिटरिंग सिस्टम उच्च दबाव वाले प्रोडक्शन संकटों के दौरान भी प्रतिक्रियाशील बने रहें।.
पूछे जाने वाले प्रश्न
मेरे कंटेनरों को किस लॉग फॉर्मेट में आउटपुट देना चाहिए?
कंटेनरों को एक समान प्रारूप में लॉग तैयार करने चाहिए, जैसे कि सादा टेक्स्ट, जो निर्देशित हो stdout तथा एसटीडेर. यह विधि लॉग स्ट्रीम को संभालने के लिए स्थापित सर्वोत्तम प्रथाओं का पालन करती है, जिससे लॉग को एकत्र करना, केंद्रीकृत करना और विश्लेषण करना आसान हो जाता है। इस दृष्टिकोण का पालन करने से लॉग एग्रीगेशन टूल के साथ एकीकरण आसान हो जाता है और कंटेनरीकृत सेटअप में लॉग प्रबंधन बेहतर होता है।.
मुझे नोड एजेंट के बजाय साइडकार का उपयोग कब करना चाहिए?
आपको क्या चाहिए प्रति-सेवा अलगाव तथा सटीक नियंत्रण व्यक्तिगत पॉड्स के भीतर लॉगिंग, मॉनिटरिंग या सुरक्षा जैसे कार्यों के लिए, एक एक प्रकार का मादक द्रव्य यही सही तरीका है। साइडकार मुख्य कंटेनर के साथ-साथ एक ही पॉड में चलती हैं, जिससे कंटेनर के कोड में कोई बदलाव किए बिना उसकी कार्यक्षमता बढ़ जाती है। यह उन्हें विशिष्ट सेवाओं के अनुरूप क्षमताएं जोड़ने के लिए एकदम सही बनाता है।.
वहीं दूसरी ओर, नोड एजेंट ये नोड स्तर पर काम करते हैं और कई पॉड्स में लॉग या मेट्रिक्स को संभालते हैं। हालांकि ये व्यापक कार्यों के लिए प्रभावी हैं, लेकिन ये व्यक्तिगत एप्लिकेशन या माइक्रोसेवाओं के लिए साइडकार द्वारा प्रदान किए जाने वाले नियंत्रण या अलगाव का समान स्तर प्रदान नहीं करते हैं।.
बैकएंड में रुकावट आने पर लॉग लॉग के नुकसान को कैसे रोका जाए?
बैकएंड में रुकावट के दौरान लॉग खोने से बचने के लिए, यह ज़रूरी है कि आपके पास निम्नलिखित सुविधाएं हों: विश्वसनीय लॉग संग्रह रणनीतियाँ स्थानीय बफरिंग और कतारबद्धता तंत्रों का उपयोग करके लॉग को तब तक अस्थायी रूप से संग्रहीत किया जा सकता है जब तक कि उन्हें डिलीवर न किया जा सके। लॉग को बफर करने और डिलीवरी को पुनः प्रयास करने के लिए डिज़ाइन किए गए उपकरण अप्रत्याशित डाउनटाइम के दौरान लॉग के खो जाने से बचाने के लिए विशेष रूप से उपयोगी होते हैं।.
स्केलेबल और रिडंडेंट सिस्टम में लॉग्स को केंद्रीकृत करना भी एक अच्छा विचार है। इससे यह सुनिश्चित होता है कि सिस्टम के कुछ हिस्सों के विफल होने पर भी लॉग्स सुलभ और सुरक्षित रहें। इसके अलावा, उचित लॉग रोटेशन और स्टोरेज नीतियां स्थापित करना महत्वपूर्ण है - यह डिस्क स्पेस को प्रभावी ढंग से प्रबंधित करने और ओवरफ्लो को रोकने में मदद करता है, जो कंटेनरीकृत वातावरण में विशेष रूप से महत्वपूर्ण है जहां संसाधन अक्सर सीमित होते हैं।.
