.NET में लॉगिंग और ट्रेसिंग के लिए सर्वोत्तम अभ्यास


53

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

मैंने यहां और इंटरनेट के माध्यम से भी इसी तरह के प्रश्न पढ़े हैं और वे वास्तव में वही चीज नहीं हैं जो मैं पूछ रहा हूं या जिनके पास संतोषजनक उत्तर नहीं है, हो सकता है कि प्रश्नों में कुछ विस्तार का अभाव हो।

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

गहराई से जाने पर, आप ट्रेसिंग और ईवेंट लॉगिंग के बीच अंतर भी कर सकते हैं, "इवेंट लॉगिंग इस ट्रेसिंग से अलग है कि यह नियंत्रण के विस्तृत प्रवाह के बजाय प्रमुख राज्यों को कैप्चर करता है"।

अब, मैं कहता हूं कि मैं केवल मानक .NET क्लासेस का उपयोग करके अपनी अनुरेखण और लॉगिंग करना चाहता हूं, जो System.Diagnosticsनामस्थान में हैं। मुझे लगा कि TraceSource क्लास स्टैटिक ट्रेस क्लास की तुलना में जॉब के लिए बेहतर है, क्योंकि मैं ट्रेस लेवल के बीच अंतर करना चाहता हूं और TraceSource क्लास का उपयोग करके मैं एक पैरामीटर को इवेंट प्रकार की सूचना देते हुए पास कर सकता हूं, जबकि ट्रेस क्लास का उपयोग करना चाहिए। Trace.WriteLineIfऔर उसके बाद जैसी चीजों को सत्यापित SourceSwitch.TraceInformationऔर SourceSwitch.TraceErrorsहै, और यह भी तरह के गुण नहीं है TraceVerboseया TraceStart

उस सब को ध्यान में रखते हुए, क्या आप इस प्रकार करने के लिए एक अच्छे अभ्यास पर विचार करेंगे:

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

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

नोट: मुझे यहाँ कुछ अच्छी जानकारी मिली है, लेकिन फिर भी मैं जो खोज रहा हूँ वह नहीं है: http://msdn.microsoft.com/en-us/magazine/ff714589.aspx



लॉगिंग के लिए अच्छे पेटेंट का उपयोग करते हुए कोई भी पूर्ण स्रोत कोड नमूना आवेदन?
कीकेनेट

ईमानदारी से ... अगर मैं .NET के साथ काम कर रहा था, तो मैं शायद न्यू रेलिक जैसा कुछ स्थापित करूंगा और इसे कॉल करूंगा। (शायद इस समय पोस्ट किया गया था, लेकिन एक अच्छा विकल्प नहीं है)
svidgen

जवाबों:


17

ट्रेस प्रकारों के महत्व को नहीं चुना जाना चाहिए क्योंकि जहां कोड में ट्रेस है, लेकिन क्योंकि ट्रेस संदेश कम या ज्यादा महत्वपूर्ण है। उदाहरण:

एक विधि शुरू करते समय एक "स्टार्ट" ईवेंट ट्रेस करें, जिसे विधि में पारित पैरामीटर मूल्यों के एक स्ट्रिंग प्रतिनिधित्व के साथ एक एकल तार्किक संचालन या एक पाइपलाइन का प्रतिनिधित्व करना चाहिए।

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

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

ट्रेसिंग पैरामीटर भी एक बुरा विचार हो सकता है । आपको यह सोचना होगा कि मामले का क्या पता लगाया जाए। उदाहरण के लिए किसी विधि के मापदंडों का पता लगाना वास्तव में बुरा है void Authenticate(string userName, string plainPassword)

डेटाबेस में कोई आइटम सम्मिलित करते समय "सूचना" घटना ट्रेस करें।

निर्भर करता है। कुछ वस्तुओं का पता लगाया जाना चाहिए, लेकिन हर आइटम पर नहीं।

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

एक महत्वपूर्ण या अगर एक बयान में एक रास्ता या किसी अन्य को लेते समय एक "सूचना" घटना का पता लगाएं।

फिर से, यह निर्भर करता है।

"क्रिटिकल" या "एरर" को एक कैच ब्लॉक में मौसम के आधार पर ट्रेस करें यह एक रिकवरी योग्य त्रुटि है।

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

विधि के निष्पादन को समाप्त करते समय एक "स्टॉप" घटना ट्रेस करें।

पहला बिंदु देखें।

कृपया स्पष्ट करें कि वर्बोज़ और चेतावनी के प्रकारों का पता लगाने के लिए सबसे अच्छा क्या है।

वर्बोस:

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

आपके पास आमतौर पर बहुत सारे संदेश हैं, जो आपको एप्लिकेशन प्रवाह को वास्तव में अच्छी तरह से समझने देते हैं। इसका अर्थ यह भी है कि उन संदेशों को अधिकांश समय अक्षम होना चाहिए क्योंकि:

  • अन्यथा, लॉग वास्तव में तेजी से बढ़ेगा,
  • आपको ज्यादातर समय उनकी जरूरत नहीं है,
  • उनमें एप्लिकेशन प्रवाह के बारे में संवेदनशील डेटा हो सकता है।

डिबगर तक पहुंच न होने पर एक उपकरण के रूप में क्रिया के बारे में सोचें, जिसका आपको उपयोग करना है।

चेतावनी:

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

उदाहरण:

  • उदाहरण 1: एप्लिकेशन उपयोगकर्ता द्वारा खोलने के लिए अनुरोध की गई फ़ाइल को खोलने में विफल रहा। फ़ाइल मौजूद है और उपयोग में नहीं है, अनुमतियाँ सही ढंग से सेट की गई हैं, लेकिन कुछ फ़ाइल के उद्घाटन को अवरुद्ध करता है। इस मामले में, आप एक त्रुटि का पता लगाएंगे , क्योंकि आपका आवेदन इस मामले को प्रबंधित नहीं कर सकता है और उपयोगकर्ता द्वारा अपेक्षित रूप से काम करना जारी रख सकता है (अर्थात वास्तव में फ़ाइल पढ़ें)।

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

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

  • उदाहरण 4: खोली गई फ़ाइल गलत तरीके से प्रदर्शित की गई है। आप वर्बोज़ ट्रेस को सक्षम करते हैं जहाँ आप वास्तव में देखते हैं कि डेटा को फ़ाइल से कैसे लोड किया जाता है और फिर पार्स किया जाता है, चरण दर चरण।


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

5
 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics महान है क्योंकि आप कॉन्फ़िगर कर सकते हैं कि कौन सी ट्रेस-जानकारी कहाँ जानी चाहिए (फ़ाइल, इवेंटलॉग, डेटाबेस, ....)

दुर्भाग्य से, यदि आप उपयोग करना चाहते हैं तो आपको System.Diagnosticsपहले से पता होना चाहिए ( पदनाम में ), जिसे ट्रेस-स्ट्रीम का पालन करना संभव होना चाहिए। (उदाहरण लेख में ये ट्रांसफर, रिज्यूमे, सस्पेंड, ...) हैं। इन्हें डिसेबल्ड, डीबगेल या एररलेवल के लिए कॉन्फ़िगर किया जा सकता है।

मैं एक लॉगिंग सिस्टम रखना पसंद करता हूं जहां मैं क्लासलेवल / नेमस्पेसल पर रनटाइम पर निर्णय ले सकता हूं कि लॉगिंग कितनी विस्तृत होनी चाहिए। उदाहरण के लिए, सभी डीबग और ऊपर से MyNamespace.Business.*लेकिन नहीं MyNamespace.Business.Calculations

यदि आप log4net (या Common.log) का उपयोग कर रहे हैं, तो हर वर्ग का अपना लकड़हारा हो जाता है, ताकि आप आसानी से तय कर सकें कि कौन सी कक्षाएं किस स्तर पर लॉग इन हुई हैं।

चूंकि डेटाबेस संचालन एक अलग वर्ग में हैं, इसलिए एक अलग नियम की आवश्यकता नहीं है

Trace an "Information" event when inserting an item into the database.

इसके बजाय मैं इन दिशानिर्देशों को प्राथमिकता देना चाहता हूं:

  • Tracelevel को मूल वर्कफ़्लो दिखाना चाहिए
  • डीबगेल को वर्कफ़्लो के भीतर विस्तृत डेटा और प्रसंस्करण दिखाना चाहिए, जिसमें कारणों के साथ प्रोग्रामफ्लो में फैसले शामिल हैं (नई आइटम बनाना क्योंकि आइटम एड से मौजूद नहीं था)
  • सेवाओं को शुरू करने / रोकने और प्रत्येक वर्कफ़्लो / जीयूआई कार्रवाई के लिए एक प्रविष्टि शुरू करने के लिए Infolevel

मैं देख रहा हूँ, यह अच्छी जानकारी है, धन्यवाद! लेकिन फिर भी, जैसा कि मैंने अपने मूल प्रश्न में पूछा है, क्या आप कृपया वर्बोज़ और चेतावनी के प्रकारों के उपयोग को स्पष्ट करेंगे? और साथ ही, मैं अन्य लोगों से उनकी बात के साथ योगदान करने के लिए कहता हूं, क्योंकि यह विषय इंटरनेट पर मेरे द्वारा देखे गए गहन अन्वेषण के योग्य है।
लेविदाद

4

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

यह स्वचालित रूप से "स्टार्ट" और "स्टॉप" अवधारणाओं को एक कहानी की शुरुआत और अंत के रूप में जोड़ देगा।

और एक नियम-आधारित प्रणाली के साथ आप यह नियंत्रित कर सकते हैं कि प्रत्येक कहानी (संदर्भ) के साथ क्या करना है, इसकी जानकारी के आधार पर, उदाहरण के लिए उन सभी कहानियों को प्रिंट करें जिनमें कोई त्रुटि है या "व्यवस्थापक" उपयोगकर्ता से आया है।

इस ब्लॉग पोस्ट की और भी जानकारी



1
अधिक जानकारी के साथ अद्यतन उत्तर
अमित Apple
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.