वितरित कार्यों के लिए एक अच्छा प्रवेश अभ्यास क्या है?

Question

मेरी निम्नलिखित सेटिंग है:

कई कार्यकर्ता बनाएं, एक संगणना करें और गणना समाप्त होने के बाद उन्हें समाप्त करें।

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

क्या यह एक अच्छा अभ्यास है? यदि नहीं, तो इस विशेष उपयोग-मामले में कार्य प्रसंस्करण को लॉग करने के लिए एक बेहतर तरीका क्या होगा?

PS: मेरा इन्फ्रास्ट्रक्चर सर्वर रहित है। तो, अब के लिए, मैं (AWS) CloudWatch पर लॉग इन कर रहा हूं। लेकिन, कृपया AWS से स्वतंत्र रूप से प्रश्न का उत्तर दें, और जितना संभव हो सर्वर रहित सेटअप का मुकदमा करें।

Answer 1

"सर्वर रहित" ज्यादातर का मतलब है कि आपको अपेक्षाकृत सरल माइक्रोसरोवर्स मिल गए हैं, आम तौर पर बस थोड़ा सा वेबैप या एक ही फ़ंक्शन होता है जो स्वचालित रूप से REST फ्रंटेंड से जुड़ा होता है। वही अवधारणाएं लागू होती हैं जो आप अधिक परंपरागत वेब सेवाओं के लिए उपयोग करते हैं: आमतौर पर दूरस्थ syslog और ElasticSearch लेखकों के कुछ मिश्रण।

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

अधिक हाल ही में, लेकिन बहुत लोकप्रिय ElasticSearch में प्रवेश कर रहा है। यह किबाना डैशबोर्ड और लॉगस्टैश टेकलीट (जिसे अक्सर ELK, ElasticSearch + Logstash + Kibana कहा जाता है) के कारण ज्यादातर उपयोगी है। अमेज़ॅन भी एक होस्टेड इलास्टिक खोज विकल्प प्रदान करता है, जिससे इसे शुरू करना कुछ आसान हो जाता है। ES अपेक्षाकृत सरल REST API का उपयोग करता है, इसलिए HTTP क्लाइंट के साथ कोई भी भाषा (पढ़ें: उन सभी) को ES में लॉगिंग के साथ ठीक होना चाहिए, लेकिन सुनिश्चित करें कि आप आंशिक सिस्टम आउटेज के मामलों में नेटवर्क संचालन को अवरुद्ध करने से सावधान रहें (यानी सुनिश्चित करें कि आपका ऐप एक लॉगिंग कॉल में फंस नहीं जाएगा जो कभी भी सफल नहीं होगा और उपयोगकर्ता के अनुरोधों को रोक देगा)।

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

"सर्वर रहित" पक्ष पर, आप आम तौर पर इन प्रणालियों के साथ सीधे नेटवर्क स्तर पर एकीकृत करना चाहते हैं, इसलिए स्थानीय फ़ाइलों को लिखने के बजाय, अपनी सेवा / फ़ंक्शन से सीधे लॉग इन करें और अपने डेटा / फ़ंक्शन से लॉग डेटा भेजें (हालांकि शायद उन पर प्रतिध्वनित करें स्थानीय डिबगिंग और विकास के लिए भी)।

Answer 2

यह उत्तर स्केलेबिलिटी विचार के बारे में अधिक है - यदि श्रमिकों की संख्या अधिक हो सकती है और / या उनमें से कई एक ही समय में उच्च दर पर लॉग का उत्पादन कर सकते हैं।

हां, एक साथ कई लॉगफाइल्स का उपयोग करना एक अच्छा अभ्यास है।

वास्तविक समय में कई श्रमिकों से एक एकल लॉगफ़ाइल लॉग में संयोजन करने का प्रयास करने से समस्याएं बढ़ेंगी:

• संदेश हानि को रोकने के लिए अवरुद्ध यंत्रों का उपयोग श्रमिकों को धीमा कर देगा
• लॉग संदेश संयुक्त लॉगफाइल में आउट-ऑफ-ऑर्डर दिखाई दे सकते हैं
• एक केंद्रीकृत लॉगिंग सुविधा जो लॉग को जोड़ती है सीमित लेखन गति के कारण अतिभारित हो सकती है, संदेश खो जाएंगे

साझाकरण लॉगफ़ाइल्स (एक ही समय में सक्रिय कई लॉगफ़ाइल्स का उपयोग करके) स्वयं एक तकनीक है जिसका उपयोग कुछ होस्टिंग प्रदाताओं द्वारा उच्च प्रदर्शन, स्केलेबल केंद्रीकृत लॉगिंग सेवाओं की पेशकश के लिए किया जाता है। उदाहरण के लिए, जब Google के स्टैकड्राइवर लॉगिंग फ़ाइलों में लॉग निर्यात करता है तो कई शार्प किए गए लॉगफाइल्स का निर्माण होता है। Google क्लाउड संग्रहण में लॉग प्रविष्टियों से :

जब आप लॉग को क्लाउड स्टोरेज बाल्टी में निर्यात करते हैं , तो स्टैकड्राइवर लॉगिंग बाल्टी में फ़ाइलों का एक सेट लिखता है। फ़ाइलों को लॉग प्रकार और दिनांक द्वारा निर्देशिका पदानुक्रम में व्यवस्थित किया जाता है। लॉग प्रकार एक साधारण नाम की तरह syslogया एक यौगिक नाम की तरह हो सकता है appengine.googleapis.com/request_log। यदि ये लॉग नाम की बाल्टी में संग्रहीत किए गए थे my-gcs-bucket, तो निर्देशिकाओं का नाम निम्न उदाहरण में दिया जाएगा:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

एक एकल बाल्टी में कई लॉग प्रकार के लॉग हो सकते हैं।

पत्ती निर्देशिका ( DD/) में कई फाइलें होती हैं, जिनमें से प्रत्येक फ़ाइल नाम में निर्दिष्ट समयावधि के लिए निर्यात की गई लॉग प्रविष्टियों को रखती है। फ़ाइलों को शार्प किया जाता है और उनका नाम एक शार्प नंबर Snया An(n = 0, 1, 2, ...) में समाप्त हो जाता है । उदाहरण के लिए, यहां दो फाइलें हैं जिन्हें निम्नलिखित में संग्रहीत किया जा सकता है directory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

इन दो फ़ाइलों को एक साथ syslog0800 UTC शुरुआत घंटे के दौरान सभी उदाहरणों के लिए लॉग प्रविष्टियाँ होती हैं । सभी लॉग प्रविष्टियों को प्राप्त करने के लिए, आपको प्रत्येक समय अवधि के लिए सभी शार्क को पढ़ना होगा - इस मामले में, फ़ाइल शार्क 0 और 1. फ़ाइल प्रविष्टियों की संख्या लॉग प्रविष्टियों की मात्रा के आधार पर हर समय अवधि के लिए बदल सकती है।

इस तरह की उच्च-प्रदर्शन लॉगिंग सेवाएं फ़ाइलों को लॉगिंग करने के लिए विकल्प भी प्रदान कर सकती हैं, लॉगफ़ाइल्स का प्रबंधन इस प्रकार पूरी तरह से बचा जा सकता है, यदि वह रुचि का हो:

• सीधे एक डेटाबेस में लॉगिंग सम्मिलित करना। उदाहरण के लिए स्टैकड्राइवर लॉगिंग लॉग को सीधे Google BigQuery में धकेल सकता है
• सीधे लॉग को एक प्रोसेसिंग इंजन में धकेलना। उदाहरण के लिए स्टैकड्राइवर लॉगिंग लॉग को Google पब / उप विषयों में धकेल सकता है

अंत में - यदि वास्तविक समय लॉगफ़ाइल विलय की आवश्यकता नहीं है, तो कई लॉगफ़ाइल्स ऑफ़लाइन लॉग प्रबंधन में मदद कर सकते हैं:

• प्रगतिशील लॉग बैकअप, संपीड़न, संग्रह और अंतिम निपटान योजनाओं को तैयार करना आसान है
• बाधाओं (लॉगफ़ाइल्स) के कई सेटों का समानांतर प्रसंस्करण संभव है, टोंटी प्रभाव को कम / कम करना
• कोई फ़ाइल विभाजन और फिर से लिखना आवश्यक नहीं है