लॉगिंग स्तर - लॉगबैक - लॉग स्तर असाइन करने के लिए नियम-से-अंगूठा

Question

मैं अपने वर्तमान प्रोजेक्ट में लॉगबैक का उपयोग कर रहा हूं ।

यह लॉगिंग के छह स्तर प्रदान करता है: TRACE DEBUG INFO WARN ERROR OFF

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

मैं प्रत्येक लॉगिंग स्तर के लिए अधिक उदाहरणों के साथ उत्तर की सराहना करूंगा।

Comments

वास्तव में उन स्तरों को जावा (SLF4J) के लिए सरल लॉगिंग मुखौटा द्वारा परिभाषित किया गया है , इंटरफेसिंग का उद्देश्य लॉगिंग कार्यान्वयन के सामने एक अग्रभाग होना चाहिए। लॉगबैक एक ऐसा कार्यान्वयन है।

— तुलसी बॉर्क

विभिन्न लॉग स्तरों का उपयोग करने के लिए

— इयाल रोथ

Answer 1

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

• त्रुटि : सिस्टम संकट में है, ग्राहक शायद प्रभावित हो रहे हैं (या जल्द ही होंगे) और फिक्स को संभवतः मानव हस्तक्षेप की आवश्यकता है। "2AM नियम" यहां लागू होता है- यदि आप कॉल पर हैं, तो क्या आप 2AM पर जागना चाहते हैं यदि यह स्थिति होती है? यदि हाँ, तो इसे "त्रुटि" के रूप में लॉग इन करें।

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

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

• डिबग : बस उस सब के बारे में जो "जानकारी" में कटौती नहीं करता है ... कोई भी संदेश जो सिस्टम के माध्यम से प्रवाह को ट्रैक करने और मुद्दों को अलग करने में सहायक होता है, खासकर विकास और क्यूए चरणों के दौरान। हम सबसे गैर-तुच्छ तरीकों के प्रवेश / निकास के लिए "डिबग" स्तर के लॉग का उपयोग करते हैं और दिलचस्प घटनाओं और निर्णय के तरीकों के अंदर अंकन करते हैं।

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

सही लॉग स्तर चुनने से अधिक या महत्वपूर्ण यह सुनिश्चित करना है कि लॉग सार्थक हैं और आवश्यक संदर्भ हैं। उदाहरण के लिए, आप लॉग में थ्रेड आईडी को लगभग हमेशा शामिल करना चाहते हैं ताकि जरूरत पड़ने पर आप किसी एक थ्रेड का अनुसरण कर सकें। आप थ्रेड के लिए व्यावसायिक जानकारी (जैसे उपयोगकर्ता आईडी) को संबद्ध करने के लिए एक तंत्र को नियोजित करना चाह सकते हैं ताकि यह भी लॉग हो जाए। अपने लॉग संदेश में, आप यह सुनिश्चित करने के लिए पर्याप्त जानकारी शामिल करना चाहेंगे कि संदेश कार्रवाई योग्य हो सकता है। "FileNotFound अपवाद पकड़ा" जैसे एक लॉग बहुत मददगार नहीं है। एक बेहतर संदेश है, "फाइलनॉटफ़ंड अपवाद को कॉन्फ़िगर फ़ाइल खोलने का प्रयास करते समय पकड़ा गया: /usr/local/app/somefile.txt। userId = 12344।"

वहाँ भी कई अच्छी लॉगिंग गाइड हैं ... उदाहरण के लिए, यहाँ JCL (जकार्ता कॉमन्स लॉगिंग) से एक संपादित स्निपेट है :

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

Comments

दिलचस्प है, इसलिए मुझे लगता है कि अगर आप एपीआई अनुरोधों को लॉग कर रहे हैं और एक उपयोगकर्ता एक पैरामीटर प्रारूप (IllegalArgumentException) के साथ एक गलती करता है, तो यह एक जानकारी स्तर है, है ना?

— एमिलियो

Answer 2

मेरा दृष्टिकोण, मुझे लगता है कि एक संचालन बिंदु से अधिक विकास से आ रहा है, यह है:

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

Answer 3

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

उदाहरण के लिए :

• "क्या एक लॉगिंग कोड लाइन जो WARN पर लॉग होती है, वास्तव में ERROR से कॉन्फ़िगर की गई मेरी तैनाती पर लॉग इन हो जाती है?" मेज कहती है, नहीं।
• "क्या एक लॉगिंग कोड लाइन जो WARN पर लॉग होती है वास्तव में DEBUG के साथ कॉन्फ़िगर की गई मेरी तैनाती पर लॉग इन होती है?" तालिका कहती है, हाँ।

से logback प्रलेखन :

अधिक ग्राफिक तरीके से, यहां बताया गया है कि चयन नियम कैसे काम करता है। निम्न तालिका में, ऊर्ध्वाधर हेडर लॉगिंग अनुरोध के स्तर को दिखाता है, जिसे पी द्वारा नामित किया गया है, जबकि क्षैतिज हेडर क्यू द्वारा नामित लॉगर के प्रभावी स्तर को दर्शाता है। पंक्तियों (स्तर अनुरोध) और स्तंभों (प्रभावी स्तर) का चौराहा मूल चयन नियम से उत्पन्न बूलियन है।

तो एक कोड लाइन जो लॉगिंग के लिए अनुरोध करती है, वास्तव में केवल तभी लॉग हो जाएगी जब उसकी तैनाती का प्रभावी लॉगिंग स्तर उस कोड लाइन की गंभीरता के अनुरोध स्तर से कम या बराबर हो ।

Answer 4

मैं इसका जवाब घटक-आधारित वास्तुकला से आता हूं, जहां एक संगठन कई घटक चला सकता है जो एक दूसरे पर भरोसा कर सकते हैं। एक प्रसार विफलता के दौरान, लॉगिंग स्तर दोनों को पहचानने में मदद करना चाहिए कि कौन से घटक प्रभावित हैं और कौन से मूल कारण हैं।

• त्रुटि - इस घटक की विफलता हुई है और इसका कारण माना जाता है कि यह आंतरिक (किसी भी आंतरिक, अखंडित अपवाद, एनकैप्सुलेटेड निर्भरता की विफलता है ... उदाहरण के लिए, डेटाबेस उदाहरण यह एक निर्भरता से 4xx त्रुटि प्राप्त होगा)। मुझे (इस घटक का अनुचर) बिस्तर से बाहर निकालो।

• WARN - इस घटक को एक आश्रित घटक के कारण होने वाली विफलता माना गया है (REST उदाहरण एक आश्रित से 5xx स्थिति होगा)। THAT घटक के अनुरक्षकों को बिस्तर से बाहर निकालें।

• जानकारी - जो कुछ भी हम एक ऑपरेटर को प्राप्त करना चाहते हैं। यदि आप खुश रास्तों को लॉग इन करने का निर्णय लेते हैं तो मैं महत्वपूर्ण संचालन के अनुसार 1 लॉग संदेश (जैसे आने वाले http अनुरोध) को सीमित करने की सलाह देता हूं।

सभी लॉग संदेशों के लिए उपयोगी संदर्भ को लॉग करना सुनिश्चित करें (और "त्रुटि" के स्थानों के बजाय संदेशों को पढ़ने योग्य / उपयोगी बनाने के लिए प्राथमिकता दें)

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

उपरोक्त लॉगिंग स्तरों की कल्पना करने का एक अच्छा तरीका प्रत्येक घटक के लिए स्क्रीन की निगरानी के एक सेट की कल्पना करना है। जब सभी अच्छी तरह से चल रहे होते हैं तो वे हरे रंग के होते हैं, यदि कोई घटक एक चेतावनी को लॉग करता है तो यह नारंगी (एम्बर) जाएगा यदि कुछ भी ERROR लॉग करता है तो यह लाल हो जाएगा।

एक घटना की स्थिति में आपके पास एक (मूल कारण) घटक लाल होना चाहिए और सभी प्रभावित घटकों को नारंगी / एम्बर जाना चाहिए।

Comments

+1 मॉनिटर सादृश्य के लिए - वास्तव में यह कल्पना करने में आपकी मदद करता है कि आपके पास इस तरह से स्तर क्यों हैं

— Emgins

Answer 5

अन्य उत्तरों के लिए अलग नहीं, मेरे ढांचे में लगभग समान स्तर हैं:

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