कैसे पता चलेगा कि बहुत अधिक लॉगिंग संदेश कब हैं?

Question

मैं CUE फ़ाइलों को पार्स करने के लिए एक बहुत अच्छी लाइब्रेरी में आया था। लेकिन जब मैं उसके स्रोत कोड को पढ़ने के लिए शुरू कर दिया, मुझे एहसास हुआ कि यह लगभग पढ़ने योग्य नहीं है:

public void setParent(final CueSheet parent) { 
    FileData.logger.entering(FileData.class.getCanonicalName(), "setParent(CueSheet)", parent); 
    this.parent = parent; 
    FileData.logger.exiting(FileData.class.getCanonicalName(), "setParent(CueSheet)"); 
} 

हर विधि logger.entering है() और logger.exiting() संदेश। क्या वह इतना ज्यादा नहीं है?

ऑडियो टैग पार्स करने के लिए एक और जावा लाइब्रेरी है। इसे पढ़ने वाली प्रत्येक फ़ाइल के लिए 15 लॉग संदेश भी थे। यह परेशान था इसलिए मैंने लॉगर को हर कॉल पर टिप्पणी की। और लाइब्रेरी तेजी से दोगुनी हो गई, क्योंकि उन्होंने लॉग संदेशों के लिए बहुत सी स्ट्रिंग कॉन्सटेनेशन का इस्तेमाल किया।

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

Answer 1

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

कभी-कभी आपको लगभग हर चीज़ लॉग इन करने की आवश्यकता होती है। प्रदर्शन या प्रदर्शन की पूरी संभावना एक आवेदन का सबसे महत्वपूर्ण हिस्सा है? यह वास्तव में निर्भर करता है।

मैंने अतीत में कई अलग-अलग वेबसाइसेस के साथ कुछ एकीकरण के साथ काम किया है, जैसे कि एक ही ऐप में 10। हमने सभी एक्सएमएल अनुरोध और प्रतिक्रियाएं लॉग की हैं। क्या यह एक उपर है? लंबी अवधि में, मुझे ऐसा नहीं लगता क्योंकि हमने बहुत से क्रेडिट कार्ड संचालन के साथ काम किया है और सर्वर से जुड़े प्रत्येक प्रक्रिया को लॉग इन करना चाहिए। कैसे जानें जब कोई बग था तब हुआ?

आप कुछ एक्सएमएल प्रतिक्रियाओं में जो देखा है उस पर आप विश्वास नहीं करेंगे। मुझे एक बड़ी हवाई जहाज कंपनी से टैग बंद किए बिना एक्सएमएल भी मिला है। क्या "अत्यधिक लॉग" एक बुरी आदत थी? कहें कि अपने ग्राहकों को जब आपको साबित करना होगा कि त्रुटि अन्य विक्रेता से आई है।

Answer 2

आदर्श रूप से, आप एक लॉगर का उपयोग करते हैं जो लॉगिंग स्तर की अनुमति देता है; log4j में घातक/त्रुटि/चेतावनी/डीबग/जानकारी है, उदाहरण के लिए। इस तरह, यदि आप "केवल त्रुटियां दिखाएं" के स्तर को सेट करते हैं, तो आप सॉफ़्टवेयर बिल्डिंग लॉग संदेशों की गति कम नहीं करते हैं जिनकी आपको आवश्यकता नहीं थी।

उसने कहा, यह तब तक बहुत अधिक लॉगिंग है जब तक कि आप लॉग इन होने वाली किसी चीज की आवश्यकता न हो जाएं। ऐसा लगता है कि अधिकांश लॉगिंग जो आपको धीमा कर रही हैं, "ट्रेस" स्तर होनी चाहिए; यह आपको दिखा रहा है कि एक प्रोफाइलर क्या होगा।

Answer 3

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

मैं मानता हूं कि यह कोड कम पठनीय बनाता है। यह एप्लिकेशन को धीमा कर देता है!

यह लाइब्रेरी के लिए एक अलग गेम है। आपके पास पर्याप्त स्तर के साथ लगातार लॉगिंग होना चाहिए। जब कोई त्रुटि होती है तो लाइब्रेरी को विकास टीम को सूचित करना चाहिए।

Answer 4

लॉगिंग आपको जानकारी प्रदान करनी चाहिए कि किसी समस्या को ट्रैक करने के लिए एक स्टैक ट्रेस नहीं कर सकता है। इसका आमतौर पर अर्थ यह है कि यह जानकारी किसी भी तरह का ऐतिहासिक निशान है जो प्रोग्राम ने किया था, क्योंकि विफलता के समय यह किस स्थिति में है।

बहुत अधिक ऐतिहासिक डेटा अनदेखा कर दिया जाएगा। यदि आप सुरक्षित रूप से कटौती कर सकते हैं कि वास्तव में अपनी प्रविष्टि और बाहर निकलने के बिना किसी विधि को बुलाया गया था, तो उन लॉगिंग प्रविष्टियों को निकालना सुरक्षित है।

एक और बुरा संकेत यह है कि यदि आपकी लॉगिंग फ़ाइलें डिस्क स्थान की एक बड़ी मात्रा का उपयोग शुरू करती हैं। आप न केवल अंतरिक्ष का त्याग कर रहे हैं, आप शायद ऐप को बहुत धीमा कर रहे हैं।

Answer 5

प्रश्न का उत्तर देने के लिए, मुझे लॉगर्स का उपयोग क्यों करना चाहिए?

क्या आपने कभी सॉफ़्टवेयर का एक टुकड़ा सामना किया है जहां अंतिम उपयोगकर्ता को प्रस्तुत किया गया एकमात्र त्रुटि Fatal error occured है। क्या यह पता लगाना अच्छा नहीं होगा कि इसके कारण क्या हुआ है?

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

यह कहकर, लॉगिंग अत्यधिक विन्यास योग्य होना चाहिए और सामान्य परिस्थितियों में न्यूनतम उत्पादन का उत्पादन करना चाहिए। इसके अलावा, गार्ड को बहुत से संसाधनों का उपभोग करने से बेहतर स्तर लॉगिंग की रक्षा करनी चाहिए।

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

Answer 6

अधिकांश प्रवेश पुस्तकालयों कि लॉगिंग पुष्टि करने के लिए एक साधन के शामिल एक निर्देश प्रक्रिया से पहले सक्षम किया गया है:

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

public void foo(ComplicatedObject bar) { 
    Logger.getInstance(Foo.class).trace("Entering foo(" + bar + ")"); 
} 

काफी महंगा bar.toString की क्षमता पर निर्भर करता है हो सकता है() तरीका। हालांकि, अगर आप के बजाय लपेट अगर कि प्रवेश स्तर के लिए एक जाँच में स्ट्रिंग संयोजन करने से पहले:

static { 
    Logger log = Logger.getInstance(Foo.class); 

public void foo(ComplicatedObject bar) { 
    if (log.isTraceEnabled()) { 
     log.trace("Entering foo(" + bar + ")"); 
    } 
} 

फिर स्ट्रिंग संयोजन केवल तभी वर्ग के लिए कम से कम एक appender ट्रेस करने के लिए सेट कर दिया जाता तब होती है। अनावश्यक स्ट्रिंग निर्माण से बचने के लिए किसी भी जटिल लॉग संदेश को ऐसा करना चाहिए।

Answer 7

पिछले कुछ सालों में मैंने उचित स्तर (ट्रेस, जानकारी, आदि ...) पर लॉगिंग सब कुछ को बढ़ावा देने के बीच पीछे और आगे बढ़े हैं और सोच रहे हैं कि कोई भी समय की पूरी बर्बादी है। हकीकत में यह इस बात पर निर्भर करता है कि ट्रैक करने या आवश्यक करने के लिए क्या उपयोगी होगा (लॉगिंग ऑडिट ट्रेल को बनाए रखने का एक सस्ता तरीका हो सकता है)।

व्यक्तिगत रूप से, मैं एक घटक या सेवा स्तर पर प्रवेश/बाहर निकलने के लिए लॉग इन करता हूं और फिर व्यवसाय तर्क निर्णय या किसी अन्य सेवा/घटक पर कॉल जैसे प्रसंस्करण में महत्वपूर्ण बिंदु लॉग करता हूं। निस्संदेह त्रुटियां हमेशा लॉग होती हैं, लेकिन एक बार केवल और उस जगह पर उन्हें संभाला जाता था (स्टैक ट्रेस और अपवाद संदेश में समस्या का निदान करने के लिए पर्याप्त जानकारी होनी चाहिए) और किसी भी सेवा/घटक इंटरफेस को हमेशा त्रुटियों को संभालना चाहिए (भले ही यह सिर्फ इसे कॉलर के लिए एक और अधिक उपयुक्त में परिवर्तित करना)।

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

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

एक बात मैंने ऐसा करने के बारे में सोचा है या देख रहा है कि किसी के पास पहले से ही एक लॉगर है जो स्मृति में प्रविष्टियां रखेगा, फिर यदि कोई त्रुटि आती है तो वे लिखे जाते हैं, यदि ऑपरेशन प्रविष्टियों को सफल करता है तो बस त्याग दिया जाता है। अगर कोई एक के बारे में जानता है (आदर्श रूप से log4j के लिए) कृपया मुझे बताएं, वैकल्पिक रूप से मेरे पास कुछ करने के बारे में कुछ विचार हैं यदि कोई भी ऐसा करने में रूचि रखता है।

Answer 8

लॉगिंग का यह स्तर कैननिक रूप से खराब है - वास्तव में, मैंने कुछ दिन पहले दैनिक डब्ल्यूटीएफ में कोड exactly like this देखा था।

लेकिन लॉगिंग सामान्य रूप से बहुत अच्छी बात है।