इनमें से कुछ कड़ाई से कॉन्फ़िगरेशन सुझावों के बजाय सामान्य NLog (या लॉगिंग) युक्तियों की श्रेणी में आते हैं।
यहाँ SO पर कुछ सामान्य लॉगिंग लिंक दिए गए हैं (आप इनमें से कुछ या सभी पहले ही देख सकते हैं):
log4net बनाम Nlog
सर्वोत्तम प्रथाओं का प्रवेश
एक लॉगिंग मुखौटा की बात क्या है?
लकड़हारा वर्ग प्रति लकड़हारा उपयोग करने की सलाह क्यों देता है?
वर्ग के आधार पर अपने लकड़हारे के नामकरण के सामान्य पैटर्न का उपयोग करें Logger logger = LogManager.GetCurrentClassLogger()। यह आपको अपने लकड़हारा में उच्च श्रेणी की ग्रैन्युलैरिटी प्रदान करता है और आपको लकड़हारा के विन्यास (विश्व स्तर पर नियंत्रण, नेमस्पेस द्वारा, विशिष्ट लकड़हारा नाम, आदि) में बहुत लचीलापन देता है।
गैर-वर्गनाम-आधारित लॉगर का उपयोग करें जहां उपयुक्त हो। शायद आपके पास एक फ़ंक्शन है जिसके लिए आप वास्तव में लॉगिंग को अलग से नियंत्रित करना चाहते हैं। शायद आपके पास कुछ क्रॉस-कटिंग लॉगिंग चिंताएं (प्रदर्शन लॉगिंग) हैं।
यदि आप classname- आधारित लॉगिंग का उपयोग नहीं करते हैं, तो अपने लॉगर्स को किसी प्रकार की पदानुक्रमित संरचना (शायद कार्यात्मक क्षेत्र द्वारा) में नाम देने पर विचार करें ताकि आप अपने कॉन्फ़िगरेशन में अधिक लचीलापन बनाए रख सकें। उदाहरण के लिए, आपके पास "डेटाबेस" कार्यात्मक क्षेत्र, "विश्लेषण" एफए, और "यूआई" एफए हो सकता है। इनमें से प्रत्येक में उप-क्षेत्र हो सकते हैं। तो, आप इस तरह लकड़हारे से अनुरोध कर सकते हैं:
Logger logger = LogManager.GetLogger("Database.Connect");
Logger logger = LogManager.GetLogger("Database.Query");
Logger logger = LogManager.GetLogger("Database.SQL");
Logger logger = LogManager.GetLogger("Analysis.Financial");
Logger logger = LogManager.GetLogger("Analysis.Personnel");
Logger logger = LogManager.GetLogger("Analysis.Inventory");
और इसी तरह। पदानुक्रमित लॉगर के साथ, आप एफए (डेटाबेस, विश्लेषण, यूआई), या सबारिया (डेटाबेस.कनेक्ट, आदि) द्वारा विश्व स्तर पर लॉगिंग ("*" या रूट लॉगर) को कॉन्फ़िगर कर सकते हैं।
लकड़हारे के पास कई विन्यास विकल्प हैं:
<logger name="Name.Space.Class1" minlevel="Debug" writeTo="f1" />
<logger name="Name.Space.Class1" levels="Debug,Error" writeTo="f1" />
<logger name="Name.Space.*" writeTo="f3,f4" />
<logger name="Name.Space.*" minlevel="Debug" maxlevel="Error" final="true" />
प्रत्येक विकल्प के अर्थ के बारे में अधिक जानकारी के लिए NLog सहायता देखें । संभवतः यहां सबसे उल्लेखनीय आइटम वाइल्डकार्ड लकड़हारा नियमों की क्षमता है, यह अवधारणा कि कई लकड़हारा नियम एकल लॉगिंग स्टेटमेंट के लिए "निष्पादित" कर सकते हैं, और एक लकड़हारा नियम को "अंतिम" के रूप में चिह्नित किया जा सकता है, इसलिए बाद के नियमों के लिए निष्पादित नहीं किया जाएगा। लॉगिंग स्टेटमेंट।
अपने आउटपुट में अतिरिक्त संदर्भ जोड़ने के लिए GlobalDiagnosticContext, MappedDiagnosticContext, और NestedDiagnosticContext का उपयोग करें।
सरलीकृत करने के लिए अपनी कॉन्फ़िगर फ़ाइल में "चर" का उपयोग करें। उदाहरण के लिए, आप अपने लेआउट के लिए चर को परिभाषित कर सकते हैं और फिर सीधे लेआउट निर्दिष्ट करने के बजाय लक्ष्य कॉन्फ़िगरेशन में चर को संदर्भित कर सकते हैं।
<variable name="brief" value="${longdate} | ${level} | ${logger} | ${message}"/>
<variable name="verbose" value="${longdate} | ${machinename} | ${processid} | ${processname} | ${level} | ${logger} | ${message}"/>
<targets>
<target name="file" xsi:type="File" layout="${verbose}" fileName="${basedir}/${shortdate}.log" />
<target name="console" xsi:type="ColoredConsole" layout="${brief}" />
</targets>
या, आप लेआउट में जोड़ने के लिए गुणों का एक "कस्टम" सेट बना सकते हैं।
<variable name="mycontext" value="${gdc:item=appname} , ${mdc:item=threadprop}"/>
<variable name="fmt1withcontext" value="${longdate} | ${level} | ${logger} | [${mycontext}] |${message}"/>
<variable name="fmt2withcontext" value="${shortdate} | ${level} | ${logger} | [${mycontext}] |${message}"/>
या, आप सामान बना सकते हैं जैसे "दिन" या "महीने" लेआउट रेंडरर्स कॉन्फ़िगरेशन के माध्यम से कड़ाई से:
<variable name="day" value="${date:format=dddd}"/>
<variable name="month" value="${date:format=MMMM}"/>
<variable name="fmt" value="${longdate} | ${level} | ${logger} | ${day} | ${month} | ${message}"/>
<targets>
<target name="console" xsi:type="ColoredConsole" layout="${fmt}" />
</targets>
आप अपने फ़ाइलनाम को परिभाषित करने के लिए लेआउट रेंडरर्स का भी उपयोग कर सकते हैं:
<variable name="day" value="${date:format=dddd}"/>
<targets>
<target name="file" xsi:type="File" layout="${verbose}" fileName="${basedir}/${day}.log" />
</targets>
यदि आप अपनी फ़ाइल को रोज़ाना रोल करते हैं, तो प्रत्येक फ़ाइल का नाम "मंडे.लॉग", "मंगलवार.लॉग", आदि हो सकता है।
अपने खुद के लेआउट रेंडर लिखने से डरो मत। यह आसान है और आपको कॉन्फ़िगरेशन के माध्यम से लॉग फ़ाइल में अपनी खुद की संदर्भ जानकारी जोड़ने की अनुमति मिलती है। उदाहरण के लिए, यहां एक लेआउट रेंडरर है (NLog 1.x, 2.0 नहीं पर आधारित) जो लॉग में ट्रेस.संरचना प्रबंधक (नेटवर्क) जोड़ सकता है।
[LayoutRenderer("ActivityId")]
class ActivityIdLayoutRenderer : LayoutRenderer
{
int estimatedSize = Guid.Empty.ToString().Length;
protected override void Append(StringBuilder builder, LogEventInfo logEvent)
{
builder.Append(Trace.CorrelationManager.ActivityId);
}
protected override int GetEstimatedBufferSize(LogEventInfo logEvent)
{
return estimatedSize;
}
}
NLog को बताएं कि आपका NLog एक्सटेंशन (किस असेंबली) इस तरह है:
<extensions>
<add assembly="MyNLogExtensions"/>
</extensions>
इस तरह कस्टम लेआउट रेंडरर का उपयोग करें:
<variable name="fmt" value="${longdate} | ${ActivityId} | ${message}"/>
Async लक्ष्य का उपयोग करें:
<nlog>
<targets async="true">
<!-- all targets in this section will automatically be asynchronous -->
</targets>
</nlog>
और डिफ़ॉल्ट लक्ष्य आवरण:
<nlog>
<targets>
<default-wrapper xsi:type="BufferingWrapper" bufferSize="100"/>
<target name="f1" xsi:type="File" fileName="f1.txt"/>
<target name="f2" xsi:type="File" fileName="f2.txt"/>
</targets>
<targets>
<default-wrapper xsi:type="AsyncWrapper">
<wrapper xsi:type="RetryingWrapper"/>
</default-wrapper>
<target name="n1" xsi:type="Network" address="tcp://localhost:4001"/>
<target name="n2" xsi:type="Network" address="tcp://localhost:4002"/>
<target name="n3" xsi:type="Network" address="tcp://localhost:4003"/>
</targets>
</nlog>
जहां उपयुक्त हो। उन लोगों के बारे में अधिक जानकारी के लिए NLog डॉक्स देखें।
यदि यह बदलता है, तो NLog को देखने और स्वचालित रूप से कॉन्फ़िगरेशन को फिर से लोड करने के लिए कहें:
<nlog autoReload="true" />
समस्या निवारण में मदद करने के लिए कई कॉन्फ़िगरेशन विकल्प हैं
<nlog throwExceptions="true" />
<nlog internalLogFile="file.txt" />
<nlog internalLogLevel="Trace|Debug|Info|Warn|Error|Fatal" />
<nlog internalLogToConsole="false|true" />
<nlog internalLogToConsoleError="false|true" />
अधिक जानकारी के लिए NLog सहायता देखें।
NLog 2.0 में LayoutRenderer रैपर जुड़ते हैं जो कि लेआउट रेंडरर (जैसे व्हाट्सएप, अपरकेसिंग, लोअरस्किंग, आदि को ट्रिम करना) के आउटपुट पर अतिरिक्त प्रोसेसिंग करने की अनुमति देता है।
आप लकड़हारा को लपेटने से डरो मत यदि आप अपने कोड को NLog पर एक कठिन निर्भरता से इन्सुलेट करना चाहते हैं, लेकिन सही तरीके से लपेटें। NLog के गितूब भंडार में लपेटने के तरीके के उदाहरण हैं। रैप करने का एक और कारण यह हो सकता है कि आप प्रत्येक लॉग किए गए संदेश में स्वचालित रूप से विशिष्ट संदर्भ जानकारी जोड़ना चाहते हैं (इसे LogEventInfo.Context में डालकर)।
रैपिंग (या अमूर्त) NLog (या उस मामले के लिए कोई अन्य लॉगिंग फ्रेमवर्क) के लिए पेशेवरों और विपक्ष हैं। थोड़े से प्रयास से, आप दोनों पक्षों को प्रस्तुत करने वाले SO पर यहाँ बहुत सारी जानकारी पा सकते हैं।
यदि आप लपेटने पर विचार कर रहे हैं, तो Common.Logging का उपयोग करने पर विचार करें । यह बहुत अच्छी तरह से काम करता है और यदि आप ऐसा करने की इच्छा रखते हैं, तो आप आसानी से किसी अन्य लॉगिंग ढांचे में स्विच कर सकते हैं। इसके अलावा यदि आप रैपिंग पर विचार कर रहे हैं, तो इस बारे में सोचें कि आप संदर्भ वस्तुओं (जीडीसी, एमडीसी, एनडीसी) को कैसे संभालेंगे। कॉमन.लॉगिंग वर्तमान में उनके लिए एक अमूर्तता का समर्थन नहीं करता है, लेकिन इसे जोड़ने की क्षमताओं की कतार में माना जाता है।
