.net - मुझे ट्रेसिंग बनाम लॉगर.नेट, एंटरप्राइज लाइब्रेरी, लॉग 4नेट या उकद आदि डायग्नोस्टिक्स का उपयोग कब करना चाहिए?




log4net enterprise-library (4)

Microsoft की बिल्ड 2013 सम्मेलन से सीखी गई कुछ चीजों को जोड़ने के लिए:

  • भारी लोड के तहत Log4NET में मुख्य रूप से एक फाइल लिखना है क्योंकि यह प्रक्रिया सिंक्रोनस है। कुछ स्थितियों में विवाद और समय समाप्त होना संभव है। यह AppDynamics या किसी अन्य समान टूल का उपयोग करके सत्यापित किया जा सकता है।

  • NLog लोडिंग के तहत कतारबद्धता को लागू नहीं करता है, IO कॉल को स्टैक अप करता है।

  • Microsoft के अनुसार, ETW कर्नेल रिंग बफ़र्स का उपयोग करता है जो अत्यधिक कुशल है। .NET 4.5 और सिमेंटिक लॉगिंग एप्लिकेशन Bock (AKA SLAB) के साथ संयुक्त ईवेंट लॉग फ्रेमवर्क इसे और अधिक कुशल बना देगा।

मैं मानक अनुरेखण, Logger.NET, Enterprise Library, log4net या Ukadc.Diagnostics के बीच चयन कैसे करूँ?

क्या ऐसी स्थिति है जहां एक दूसरे की तुलना में अधिक उपयुक्त है? ... वो क्या हो सकता है? (ASP.NET, कंसोल ऐप, Azure Cloud, SOHO, Enterprise ...)

लाभ या कमियां क्या हैं?

क्या मुझे कोई अन्य प्रमुख लॉगिंग फ्रेमवर्क याद आया?


एसओ पर यहां कई समान प्रश्न हैं:

आप कई सामान्य रूप से उपयोग किए गए लॉगिंग फ़्रेमवर्क से चूक गए। यहां आमतौर पर उपयोग किए जाने वाले फ्रेमवर्क की एक सूची दी गई है, जिनमें से कुछ आपने सूचीबद्ध किए हैं:

लॉगिंग सार:

System.Diagnostics addons:

अन्य

कोडप्लेक्स से कुछ अन्य लॉगिंग फ्रेमवर्क (जो मैंने SO पर यहां देखा है):

आप एक को दूसरे पर क्यों चुन सकते हैं? वह काफी मुश्किल है। इसमें से बहुत कुछ व्यक्तिगत पसंद है। इसमें से कुछ तकनीकी (या सुविधा) श्रेष्ठता है।

किसी भी लॉगिंग ढांचे (विशेष रूप से तृतीय-पक्ष वाले) का एक स्पष्ट दोष समर्थन की गुणवत्ता है। यदि आपके पास log4net, NLog, Common.Logging, आदि के साथ कोई समस्या है तो क्या होगा? क्या आप उन चौखटे के डेवलपर्स से फिक्स प्राप्त कर पाएंगे? यह बहुत महत्वपूर्ण नहीं हो सकता क्योंकि इन रूपरेखाओं के लिए स्रोत कोड उपलब्ध है। हालाँकि, आप स्रोत के पेड़ को "विरासत में" प्राप्त करना पसंद नहीं कर सकते हैं। मैं कहूंगा कि रूपरेखा इतनी व्यापक है, कि सामान्य विस्तार बिंदुओं के माध्यम से कई संवर्द्धन जोड़े जा सकते हैं।

यदि आप उन लिंक्स को पढ़ते हैं जो मैंने ऊपर पोस्ट किए हैं, तो मुझे लगता है कि यह कहना उचित है, केवल अनुकूल उल्लेखों की मात्रा के आधार पर, यह लॉग 4नेट स्पष्ट "विजेता" होगा। यह ऐतिहासिक लॉगिंग पसंदीदा के रूप में अधिक बार उल्लेख किया जाएगा और आगे बढ़ने के लिए कौन से लोग इसका उपयोग करना पसंद करेंगे।

NLog के पास इसके समर्थक हैं, बस लगता है कि प्रवेश, या "मन के ऊपर" जागरूकता जो log4net करता है, भले ही वे बहुत समान हों। NLog की क्षमताएं log4net से बहुत मिलती-जुलती हैं और हाल ही में एक महत्वपूर्ण विकास चक्र से गुजरने का इसका अतिरिक्त लाभ है।

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

System.Diagnostics को अक्सर कम से कम तीन मजबूत लाभों के साथ एक उचित विकल्प के रूप में अनुशंसित किया जाता है: कोई तृतीय पक्ष निर्भरता नहीं, कई Microsoft घटकों को System.Diagnostics के साथ इंस्ट्रूमेंट किया जाता है, यह आसानी से विस्तार योग्य है (संभवतः कुछ क्षमताओं को जोड़ने के लिए जो पहले से ही मुफ्त में मौजूद हैं log4net और NLog? जैसे फ्रेमवर्क में?) यदि आप System.Diagnostics का उपयोग करते हैं, तो मुझे लगता है कि Trace.WriteLine / Debug.WriteLine के बजाय TraceSource ऑब्जेक्ट का उपयोग करने के लिए आम सहमति (जैसा कि मेरी सिफारिश होगी) होगी।

यह भी ध्यान दें कि System.Diagnostics और WCF एक साथ अच्छी तरह से काम करते हैं। WCF संदेश ट्रैफ़िक को System.Diagnostics के साथ लॉग इन किया जा सकता है और WCF WCF सीमा सीमाओं के पार System.Diagnostics गतिविधि सूचना (System.Diagnostics.CorrelationManager.ActivityId) का भी प्रचार करेगा।

मुझे यकीन नहीं है कि log4net को अपनी सबसे पसंदीदा स्थिति बनाए रखना चाहिए। जैसा कि एसओ पर यहां कहीं और नोट किया गया है, log4net को हाल ही में बहुत अधिक विकास नहीं हो रहा है (ध्यान दें कि मुझे लगता है कि "log4net मर चुका है" एक अतिशयोक्ति है), जबकि NLog 2.0 वर्तमान में अंतिम रिलीज के साथ बीटा में Q1 में अपेक्षित है। 2011 (अद्यतन: NLog 2.0 जुलाई 17, 2011 को जारी किया गया था )। क्या यह NLog को log4net की तुलना में स्पष्ट रूप से बेहतर विकल्प बनाता है? मुझे नहीं पता, लेकिन मुझे लगता है कि, अपेक्षाकृत कम बोलने पर, NLog को कम से कम समान विचार प्राप्त करना चाहिए जब दोनों के बीच चयन करना चाहिए और, शायद, नए विकास के लिए पसंदीदा माना जाना चाहिए, कम से कम जब तक log4net विकास जीवन के अधिक संकेत नहीं दिखाता है।

log4net और NLog दोनों ही बहुत लचीले विन्यास विकल्प प्रदान करते हैं। वे आपको अपने लॉगिंग स्टेटमेंट्स की परिभाषा में बहुत बढ़िया ग्रैन्युलैरिटी प्रदान करने की अनुमति देते हैं (प्रति प्रकार लकड़हारे को परिभाषित करने के "मानक" पैटर्न द्वारा)। वे आपको अपने स्वयं के "लॉगिंग डेस्टिनेशन" ऑब्जेक्ट (log4net Appenders और NLog Targets) और "फ़ॉर्मेटिंग" ऑब्जेक्ट (log4net पैटर्न कन्वर्टर्स और NLog LayoutRenderers) को विकसित करने की अनुमति देकर पुस्तकालयों के आसान विस्तार के लिए भी अनुमति देते हैं।

एक लॉगिंग फ्रेमवर्क पसंद के अलावा, कुछ (कई?) एक अमूर्त परत के उपयोग से एक विशेष लॉगिंग फ्रेमवर्क पर एक कठिन निर्भरता से अपने आवेदन कोड को इन्सुलेट करने की वकालत करते हैं। यह आपके अपने ILogger इंटरफ़ेस का रूप ले सकता है जिसे आप लागू करते हैं, शायद मौजूदा ढांचे के शीर्ष पर। भविष्य में, आप अपने ILogger को एक अलग फ्रेमवर्क पर लागू करके फ्रेमवर्क बदल सकते हैं। या, आप "ILogger" को अपने कोड में इंजेक्ट करने के लिए DI / IoC का उपयोग कर सकते हैं। कई DI / IoC चौखटे एक अंतर्निहित ILogger अमूर्त प्रदान करते हैं जिन्हें लॉग 4net, NLog, या एंटरप्राइज़ लाइब्रेरी का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है या आप अपना खुद का ILogger कार्यान्वयन लिख सकते हैं और इसे इंजेक्ट कर सकते हैं)। कौन परवाह करता है कि कार्यान्वयन क्या है? एक विशिष्ट लॉगिंग ढांचे पर एक कठिन निर्भरता होने से अपने कोड को इन्सुलेट करने का एक और तरीका कॉमन लॉगिंग या एसएलएफ जैसे मौजूदा लॉगिंग अमूर्त ढांचे के उपयोग के माध्यम से है। लाभ यह है कि, फिर से, आपका आवेदन एक विशिष्ट लॉगिंग ढांचे पर निर्भर नहीं है। हालांकि, कुछ लोग कहेंगे कि आपने केवल एक निर्भरता (एक लॉगिंग फ्रेमवर्क पर) दूसरे के लिए (लॉगिंग एब्स्ट्रैक्शन फ्रेमवर्क) कारोबार किया है।

अमूर्त लॉगिंग के बारे में दो और नोट:

  1. एक अच्छा लॉगिंग अमूर्त आपको एक ही आउटपुट फ़ाइल में विभिन्न लॉगिंग फ्रेमवर्क से आउटपुट कैप्चर करने की अनुमति देनी चाहिए। कॉमन.लॉगिंग इसे "ब्रिजिंग" कहता है। कहें कि आपने कॉमन.लॉगिंग का उपयोग करते हुए एक ऐप लिखा है, जो कि NLog द्वारा समर्थित है। अब कहते हैं कि आप किसी तीसरे पक्ष के पुस्तकालय का उपयोग कर रहे हैं जो सीधे log4net का उपयोग करके लिखा गया है। एक ब्रिजिंग सिस्टम के साथ, आप log4net आउटपुट (एक कस्टम ऐपेंडर के माध्यम से) पर कब्जा कर सकते हैं और इसे Common.Logging के माध्यम से रीरूट कर सकते हैं ताकि आपके ऐप के लॉगिंग आउटपुट के संदर्भ में थर्ड पार्टी क्लास लाइब्रेरी के लॉगिंग आउटपुट को देखा जा सके।

  2. लॉगिंग एब्स्ट्रैक्शन का उपयोग करना आपको विकास के दौरान लॉगिंग फ्रेमवर्क को "टेस्ट ड्राइव" करने की अनुमति देता है। आप यह सोचना शुरू कर सकते हैं कि लॉग 4नेट जाने का एक तरीका है, लेकिन आप खुद को एनएलओजी के लिए खुला छोड़ना चाहते हैं। लॉगिंग एब्स्ट्रैक्शन का उपयोग करना दोनों के बीच स्विच करना अपेक्षाकृत आसान है। अंत में, आप यह चुन सकते हैं कि किस लॉगिंग फ्रेमवर्क का चयन किया गया है, लेकिन, इस बीच, आप कोड के पहाड़ों को लिखने में सक्षम हो गए हैं जो किसी विशिष्ट लॉगिंग ढांचे पर किसी भी तरह से निर्भर नहीं हैं।

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

यदि आप सिल्वरलाइट में विकसित कर रहे हैं तो क्या होगा? आप क्लॉग जैसे कुछ का उपयोग करने के लिए चुन सकते हैं - कैल्शियम का हिस्सा । आप NLog 2.0 का उपयोग करना चुन सकते हैं, जो सिल्वरलाइट और WP7 संगत है।

System.Diagnostics addons (Ukadc.Diagnostics, Essential.Diagnostics)। ये प्रति फ्रेमवर्क लॉगिंग नहीं हैं। बल्कि, वे उपयोगी वस्तुओं और विस्तार बिंदुओं के संग्रह का प्रतिनिधित्व करते हैं जो मौजूदा System.Diagnostics ढांचे के साथ उपयोग किया जा सकता है। सबसे अच्छी बातों में से एक, मेरी राय में, कि इनमें से प्रत्येक ऐडऑन आपके लॉगिंग आउटपुट को प्रारूपित करने की क्षमता है, आप इसे log4net और NLog के साथ कैसे प्रारूपित कर सकते हैं। मैंने Essential.Diagnostics का उपयोग नहीं किया है, लेकिन मैंने Ukadc.Diagnostics के साथ प्रयोग किया है और लगता है कि यह वास्तव में अच्छा है। अपने स्वयं के "फ़ॉर्मेटिंग टोकन" लिखना और भी आसान है।

मुझे नहीं पता कि यह आपके प्रश्न का पूरी तरह से उत्तर देता है (जो वैसे भी बहुत व्यापक है), लेकिन मुझे लगता है कि यहां विचार के लिए बहुत सारे भोजन हैं।


मैं log4j या log4net का प्रशंसक नहीं हूं। मुझे java.util.net लॉगिंग सुविधा पसंद है, और इसलिए मैंने इसे पुनः बनाया है, अधिकांश भाग के लिए, https://github.com/greggwon/NetLog/ पर NetLog नाम के गिथब प्रोजेक्ट पर। प्रतिक्रिया देने के लिए स्वतंत्र महसूस करें। मैं एक logging.properties फ़ाइल के बदले में कॉन्फ़िगरेशन प्रबंधक आधारित कॉन्फ़िगरेशन में डालने के लिए कुछ समय देने की कोशिश कर रहा हूं। Java.util.log के साथ, कमांड लाइन प्रॉपर्टी सेटिंग्स का उपयोग करना हमेशा आसान होता था, यह निर्दिष्ट करने के लिए कि लॉग इन कहां था। यदि आप कॉन्फ़िगरेशन प्रबंधक का उपयोग नहीं करते हैं, तो यह .net के साथ बहुत अधिक दर्दनाक है। सीएम के लिए समर्थन प्रदान करने से, लॉगर और हैंडलर के बीच कुछ अलग रिश्तों के लिए दरवाजा खुल जाएगा जो कुछ चीजों को बेहतर बना सकते हैं।

NetLog में एक EventLogHandler शामिल होता है जो सिस्टम इवेंटलॉग में लॉग इन करेगा। इसका एक Level.EventLog स्तर भी है, जो आपको "चेतावनी" के नीचे सेट करता है, जो आपको "WARNING" या "SEVERE" का उपयोग किए बिना EventLog को लक्षित करने के लिए "नामित" स्तर की अनुमति देगा। मेरे पास एक TCPSocketHandler भी है जो आपको "लॉगिंग" में टेलनेट देता है ताकि आप "पूंछ" प्रोग्राम के बिना "पूंछ" पर उपलब्ध हो सकें।


मैंने अभी VS2010 में log4net का उपयोग करना शुरू किया और पाया कि इसमें System.Web पर निर्भरता है ... जो इसे ".NET xx क्लाइंट प्रोफाइल" फ्रेमवर्क लक्ष्यों के साथ असंगत बनाता है ... यह देखते हुए कि यहां किसी ने विंडोज अपडेट का उपयोग करके विंडोज अपडेट के बारे में क्या पोस्ट किया है। पसंद के .NET पुनर्वितरण के रूप में क्लाइंट प्रोफाइल, इसका मतलब यह है कि log4net अब पसंद का लकड़हारा नहीं हो सकता है यदि आप अपने कोड को मशीनों के बहुमत पर चलाना चाहते हैं ...

अन्य विकल्पों की जानकारी के लिए धन्यवाद - मैं उनकी जाँच करूँगा ...





system.diagnostics