हमने एक थर्ड पार्टी प्लेटफार्म (गीगास्पेस) का उपयोग करना शुरू कर दिया है जो हमें वितरित कंप्यूटिंग के साथ मदद करता है। अब हम जिन समस्याओं को हल करने की कोशिश कर रहे हैं उनमें से एक यह है कि इस वितरित वातावरण में हमारी लॉग फ़ाइलों को कैसे प्रबंधित किया जाए। वर्तमान में हमारे पास निम्नलिखित सेटअप है।कई मशीनों पर वितरित लॉग फ़ाइलों की एक बड़ी संख्या का प्रबंधन
हमारा प्लेटफार्म 8 मशीनों पर वितरित किया जाता है। प्रत्येक मशीन पर हमारे पास 12-15 प्रक्रियाएं होती हैं जो java.util.logging का उपयोग करके लॉग फ़ाइलों को अलग करने के लिए लॉग इन करती हैं। इस मंच के शीर्ष पर हमारे पास हमारे स्वयं के अनुप्रयोग हैं जो log4j का उपयोग करते हैं और फ़ाइलों को अलग करने के लिए लॉग इन करते हैं। हम थ्रेड डंप और इसी तरह के पकड़ने के लिए stdout को एक अलग फ़ाइल में रीडायरेक्ट भी करते हैं।
इसके परिणामस्वरूप 200 अलग-अलग लॉग फ़ाइलें होती हैं।
अभी तक हमारे पास इन फ़ाइलों को प्रबंधित करने में सहायता करने के लिए कोई टूलिंग नहीं है। निम्नलिखित मामलों में यह हमें गंभीर सिरदर्द का कारण बनता है।
समस्या निवारण जब हम पहले से नहीं जानते कि समस्या किस प्रक्रिया में हुई थी। इस मामले में हम वर्तमान में एसएसएच का उपयोग करके प्रत्येक मशीन में लॉग इन करते हैं और
grepका उपयोग शुरू करते हैं।सामान्य से कुछ भी के लिए नियमित रूप से लॉग की जांच करके सक्रिय होने की कोशिश कर रहा है। इस मामले में हम वर्तमान में सभी मशीनों में लॉग इन करते हैं और
lessऔरtailका उपयोग करके विभिन्न लॉग देख सकते हैं।अलर्ट सेट अप करना। हम थ्रेसहोल्ड पर घटनाओं पर अलर्ट सेट अप करना चाहते हैं। यह जांचने के लिए 200 लॉग फाइलों के साथ दर्द होना चाहता है।
आज हम प्रति सेकंड केवल लगभग 5 लॉग ईवेंट को है, लेकिन जैसा कि हम नए मंच करने के लिए अधिक से अधिक कोड विस्थापित कि वृद्धि होगी।
मैं समुदाय से निम्नलिखित प्रश्न पूछना चाहता हूं।
- आपने विभिन्न ढांचे के माध्यम से कई मशीनों पर वितरित कई लॉग फ़ाइलों के साथ समान मामलों को कैसे संभाला है?
- आपने उस विशेष समाधान का चयन क्यों किया?
- आपके समाधान कैसे काम करते हैं? आपको अच्छा क्या मिला और आपको बुरा क्या मिला?
बहुत धन्यवाद।
अद्यतन
हम Splunk का परीक्षण संस्करण का मूल्यांकन समाप्त हो गया। हम इस बात से बहुत खुश हैं कि यह कैसे काम करता है और इसे खरीदने का फैसला किया है। तकनीकी रूप से इच्छुक के लिए सेट अप, तेज़ खोज और सुविधाओं का एक टन आसान है। मैं इसे जांचने के लिए इसी तरह की परिस्थितियों में किसी को भी सिफारिश कर सकता हूं।
यह इंगित करने योग्य है कि स्क्रिप्ट के लिए सब कुछ पुनर्निर्देशित करना अनिवार्य रूप से एक बना देगा प्रणाली में विफलता का एक बिंदु, उदाहरण के लिए जब स्क्रिप्ट डिमन नीचे है। –
ठीक है, अंतिम समाधान का गलती सहनशीलता पहलू आम तौर पर बहुत ही तैनाती-विशिष्ट है और इस तरह, अंतिम समाधान के लिए जिम्मेदार वास्तुकार के लिए एक अभ्यास के रूप में छोड़ दिया गया है। फिर भी, यह ध्यान में रखना कुछ है। –
मैं यह जोड़ना चाहता हूं कि यह वास्तव में एक वास्तविक "विफलता का एक बिंदु" नहीं है, यदि सिंक केंद्रीय नोड नीचे है, तो संपूर्ण समाधान अप्रभावित है - व्यक्तिगत स्क्रिप्ट नोड्स स्थानीय नोड वापस होने तक स्थानीय रूप से लॉग रिकॉर्ड कतारबद्ध करते हैं फिर से ऊपर। स्क्रिप्ट डाउनटाइम केवल लॉगिंग सबसिस्टम उपलब्धता को प्रभावित करता है। –