अपवादों के लिए त्रुटि लॉगिंग को प्रबंधित करने का सबसे अच्छा तरीका क्या है?

Question

परिचय

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

और अगर आपके पास बहुत सारी प्रणालियाँ हैं, तो आप नहीं चाहते हैं कि यह जानकारी चारों ओर बिंदीदार हो - इसके लिए एक ही केंद्रीकृत स्थान होना अच्छा है।

सबसे सरल स्तर पर, सभी की जरूरत है एक वृद्धिशील आईडी और त्रुटि विवरणों का क्रमबद्ध डंप। (और संभवतः "केंद्रीकृत स्थान" एक ईमेल इनबॉक्स हो सकता है।)

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

जो मैं यहां बता रहा हूं वह कोड-स्तर की त्रुटियों / अपवादों को दूरस्थ प्रणाली द्वारा लॉग कर रहा है - न कि "मानव-आधारित" समस्या ट्रैकिंग, जैसे कि जीरा, टीआरसी, आदि के साथ किया गया।

प्रशन

मैं उन डेवलपर्स के विचारों की तलाश कर रहा हूं जिन्होंने इस प्रकार की प्रणाली का उपयोग किया है, विशेष रूप से इस संबंध में:

• ऐसी कौन सी आवश्यक सुविधाएँ हैं जिनके बिना आप नहीं कर सकते?
• उन विशेषताओं के लिए क्या अच्छा है जो वास्तव में आपका समय बचाती हैं?
• क्या सुविधाएँ एक अच्छा विचार लग सकता है, लेकिन वास्तव में यह उपयोगी नहीं हैं?

उदाहरण के लिए, मैं एक "शो डुप्लिकेट" फ़ंक्शन कहूंगा जो एक त्रुटि की कई घटना की पहचान करता है ('महत्वहीन' विवरणों के बारे में चिंता किए बिना) भिन्न हो सकता है।
एक बटन "इस त्रुटि के लिए [जीरा / आदि] में एक मुद्दा बनाने के लिए" एक अच्छा समय बचाने जैसा लगता है।

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

Comments

एक बात याद रखें: यदि आप कुछ लॉग कर रहे हैं, तो कुछ गलत हो गया है, और एक से अधिक चीजें गलत हो सकती हैं। लॉगिंग क्रियाओं को सरल पक्ष पर रखें।

— डेविड थॉर्नले

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

मैंने अपवाद लकड़हारे देखे हैं जो String.Format (C #) :) पर खुद एक अपवाद फेंकते हैं। लॉगगिन को सरल रखें, अधिमानतः जोखिम-रहित, गतिशील नहीं (जैसे आप किसी अपवाद को लॉग इन करने का प्रयास कर रहे हैं तो XML फ़ाइल को पार्स न करें)। यदि आप कर सकते हैं त्रुटि लॉगिंग में गतिशीलता से बचें। यदि आपके पास एक xml फ़ाइल में कॉन्फ़िगर किया गया सामान है, तो मुझे लगता है कि रन-टाइम पर उस कॉन्फिग फ़ाइल को पार्स करने के बजाय, इसके (ठोस) आधार पर कुछ वास्तविक कोड जेनरेट करना बेहतर है, जब आप किसी त्रुटि की रिपोर्ट कर रहे हों (डायनामिक) )। वैसे भी मेरा अनुभव यही था। आप लॉगिंग के लिए एक प्लान बी रखना चाह सकते हैं - यदि फैंसी आउटपुटिंग विफल हो जाती है, तो लॉग ऑन करें

— जॉब

SO से कुछ लॉगिंग संबंधित लिंक हम क्या लॉग करते हैं और हम इसे क्यों लॉग करते हैं? जावा में लॉगिंग के साथ क्या है? सबसे अच्छा अभ्यास लॉगिंग

— pramodc84

Answer 1

मैं एक ऐसी परियोजना में रहा हूँ जहाँ Microsoft एंटरप्राइज़ लाइब्रेरी का उपयोग करके लॉग क्लाइंट त्रुटियों के साथ । सभी अपवाद जहां हमारे मेल बॉक्स में भेजे जाते हैं मेल विषय में हमने डुप्लिकेट संदेशों से बचने के लिए क्रमबद्ध त्रुटि के हैश कोड को जोड़ा। डेटाबेस में धारावाहिक संदेशों को स्टोर कर सकता है।

मैं आपको Microsoft एंटरप्राइज़ लाइब्रेरी और लॉग 4नेट की जांच करने की सलाह देता हूं ।

Log4Net की कुछ विशेषताएं

• कई चौखटों के लिए समर्थन
• कई लॉगिंग लक्ष्य के लिए आउटपुट
• पदानुक्रमित लॉगिंग वास्तुकला
• XML कॉन्फ़िगरेशन
• गतिशील विन्यास
• लॉगिंग प्रसंग
• सिद्ध वास्तुकला
• मॉड्यूलर और एक्स्टेंसिबल डिज़ाइन • लचीलेपन के साथ उच्च प्रदर्शन

Comments

एक अच्छा लकड़हारा आपको अपनी त्रुटियों को अपनी पसंद (ईमेल, DB, फ़ाइल, आदि) की दृढ़ता के लिए धकेल देगा।

— केन हेंडरसन

Answer 2

डेटाबेस अनुप्रयोगों के मामले में, कुछ प्रकार की आईडी (जैसे <TABLE>:<PrimaryKeyID>) जो आपको उस दायरे से संबंधित डेटाबेस में रिकॉर्ड को ट्रैक करने की अनुमति देती है जहां अपवाद पकड़ा गया था।

मैंने इसे ओरेकल और पीएल / एसक्यूएल के साथ किया है, आईडी को एक डेटाबेस तालिका में अपवाद हैंडलर से, रिकॉर्डिंग के भीतर।

Comments

कम से कम तालिका को रिकॉर्ड करने और संसाधित होने के लिए रिकॉर्ड अच्छा है। बेहतर अभी भी बेशक एसक्यूएल बयान (और किसी भी पैरामीटर) का प्रयास कर रहा है।

— पीटर बॉटन

Answer 3

आप जो कुछ भी वर्णन करते हैं उनमें से अधिकांश (यानी लॉगिंग विशिष्ट भागों) उद्यम पुस्तकालय में लागू होते हैं जैसा कि अमीर रज़ाई ने नोट किया है। बाकी सब कुछ एनालिटिक्स का हिस्सा लगता है (यानी बाद में लॉग के साथ क्या करना है)।

मेरे मामले में, मैंने कुछ छोटे ऐप और sql स्क्रिप्ट बनाए, जिनसे कुछ चीजें आसान हुईं। यहाँ कुछ चीजें हैं जो मुझे बहुत पसंद हैं:

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

Answer 4

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

# Create socket.
my $sock = IO::Socket::INET->new(
    Proto       => 'udp',
    PeerAddr    => $bcastaddr,
    Broadcast   => 1,
) or die "Can't create socket ($bcastaddr): $!";

while (<>) {
    chomp;
    unless (/File\ does\ not\ exist:/) {
        $sock->send("$eventtype:$_") or warn "Can't send: $!";
    }
}

फिर एक विश्लेषक यह बता सकता है कि वह क्या देखना चाहता है।

Comments

यकीन नहीं होता कि 'फायरहोज़' क्या है? आज डिस्क की क्षमता को देखते हुए, मुझे उम्मीद है कि त्रुटियां इतनी सामान्य नहीं थीं कि लॉग आकार एक मुद्दा होगा।

— पीटर बॉटन

Answer 5

यहाँ कुछ चीजें मैंने अपने अनुप्रयोगों में त्रुटि निगरानी से सीखी हैं:

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

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

Answer 6

elmah ASP.NET ऐप्स के लिए एक ओपन सोर्स एरर लॉगिंग सिस्टम है और इसे मौजूदा सिस्टम (NuGet http://nuget.codeplex.com/ का उपयोग करके ) को जल्दी और आसानी से जोड़ा जा सकता है । यह विभिन्न बैकएंड और अधिसूचना कार्यों का समर्थन करता है।

मैं किसी ऐसे व्यक्ति के बारे में नहीं जानता, जिसने इसे डेस्कटॉप ऐप में जोड़ा हो क्योंकि यह एक वेबसाइट के रूप में चलता है, लेकिन कुछ भी नहीं है जो आपको इसे सेवा के रूप में चलाने और वेब के माध्यम से अपने अपवाद पोस्ट करने से रोक रहा है।

http://code.google.com/p/elmah/

ELMAH (त्रुटि लॉगिंग मॉड्यूल और हैंडलर) एक एप्लिकेशन-वाइड त्रुटि लॉगिंग सुविधा है जो पूरी तरह से प्लग करने योग्य है। यह गतिशील रूप से एक चल रहे ASP.NET वेब अनुप्रयोग में जोड़ा जा सकता है, या फिर मशीन पर सभी ASP.NET वेब अनुप्रयोगों को फिर से संकलन या पुनः तैनाती की आवश्यकता के बिना जोड़ा जा सकता है ।

एक बार ELMAH को एक रनिंग वेब एप्लिकेशन में छोड़ दिया गया है और उचित रूप से कॉन्फ़िगर किया गया है, तो आपको अपने कोड की एक पंक्ति को बदले बिना निम्नलिखित सुविधाएं मिलती हैं:

• लगभग सभी अखंडित अपवादों का लॉगिंग।
• रिमोट किए गए अपवादों के पूरे लॉग को दूरस्थ रूप से देखने के लिए एक वेब पेज।
• किसी वेब पेज को दूरस्थ रूप से देखने के लिए एक वेब पेज, जिसमें रंगीन स्टैक के निशान सहित किसी भी एक लॉग इन अपवाद का पूरा विवरण है।
• कई मामलों में, आप मौत के मूल पीले स्क्रीन की समीक्षा कर सकते हैं जो ASP.NET किसी दिए गए अपवाद के लिए उत्पन्न होता है, यहां तक ​​कि customErrorsमोड बंद होने के साथ भी ।
• उस समय होने वाली प्रत्येक त्रुटि की ई-मेल सूचना।
• लॉग से अंतिम 15 त्रुटियों का RSS फ़ीड ...

Comments

ELMAH अविश्वसनीय है। अगर httpcontext NULL ==> बूम है

— Quandary

अगर मैं कुछ याद कर रहा हूँ तो मुझे आश्चर्य होगा? जब हम किसी एप से ELMAH में लॉग इन करने का प्रयास करते समय एक त्रुटि देखते हैं और HttpContext शून्य है, लेकिन यदि आपके पास रूट स्तर की पकड़ है -> शून्य संदर्भ और लॉग के साथ नया एल्माह लॉगर बनाएं, तो यह ठीक काम करता है। वहाँ एक सामान्य ASP.NET वेबसाइट में जगह है कि यह कोशिश कर सकते हैं और लॉग इन करें और HttpContext शून्य है?

— इयान ग्रिंगर