🧗🏼 🍖 🛃 लॉग आर्किटेक्चर 👨🏿‍🏭 🕴️ 🧚🏼

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

विषय इस लेख के लिए एक निरंतरता के रूप में लिखा गया है और मुख्य रूप से नौसिखिए प्रोग्रामर के लिए उपयोगी होगा।

यहाँ मैं निम्नलिखित मुद्दों पर प्रकाश डालने जा रहा हूँ:

सॉफ्टवेयर का उपयोग करने वाले लॉगर और उदाहरणों की आंतरिक संपत्ति।
वॉल्यूम, स्तर और लॉग संदेशों का विवरण।
सामान्य विन्यास नियम विकास में, लड़ाई में, और जांच में।

इसलिए, मैं पिछले लेख में अपने परिवर्धन के साथ शुरू करूंगा।
लेखक की तरह, मैं NLog का उपयोग करता हूं और निश्चित रूप से, इसकी विशेषताओं का व्यापक रूप से उपयोग करता हूं। के बाद बेशक
किसी भी अन्य लकड़हारे में उनके कार्यान्वयन, नीचे वर्णित अभ्यास उन पर लागू किया जा सकता है।

वैसे, log4net का विकास जारी है ।

वास्तव में, "एक सम्मानित लकड़हारे की सुविधाएँ" के लिए केवल दो आवश्यक अतिरिक्त हैं:

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

हुड NLog के तहत

दूसरी सुविधा की उपयोगिता पर तुरंत चर्चा करें।

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

जाहिर है, एक सैन्य आवेदन में, यहां तक कि विस्तृत लॉगिंग बंद भी निष्पादन की गति और समानता दोनों के साथ हस्तक्षेप कर सकता है।

NLog निम्नलिखित तकनीकों का उपयोग करता है:

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

कक्षा का स्रोत कोड यहां पाया जा सकता है ।

बहुत बढ़िया! NLog के लिए, आप यह सुनिश्चित कर सकते हैं कि आपके मनमाने ढंग से विस्तृत संदेशों को निष्क्रिय किया जा सकता है और इससे प्रदर्शन पर कम से कम प्रभाव पड़ेगा। लेकिन, यह लॉगिंग के लिए आधे कोड को समर्पित करने का एक कारण नहीं है।

क्या और कैसे लॉग इन करें

नियमों का पालन किया जाना चाहिए:

लॉग के आउटपुट को एक अलग लाइन पर रखा जाना चाहिए।
संदेश यथासंभव छोटा और सूचनात्मक होना चाहिए।
केवल दुर्लभ या घातक संदेश स्थानीयकृत किए जा सकते हैं।
किसी विधि के स्थानीय चर या किसी वर्ग विधि के आंतरिक वर्ग चर से तर्क लेना उचित है।
प्रकार के रूपांतरणों का उपयोग करना उचित नहीं है।

सामान्य तौर पर, लॉग के लिए आउटपुट करते समय, हमेशा संभावित अनावश्यक गणनाओं की संख्या पर ध्यान दें जो लॉग के अक्षम होने पर मामले के लिए आवश्यक होंगे।

सरल उदाहरण (कुछ वर्ग का टुकड़ा):

private static Logger Log = LogManager. GetCurrentClassLogger ( ) ; public string Request ( string cmd, string getParams ) { Uri uri = new Uri ( _baseUri, cmd + "?" + getParams ) ; Log. Debug ( "Request for uri:`{0}'" , uri ) ; HttpWebRequest webReq = ( HttpWebRequest ) WebRequest. Create ( uri ) ; webReq. Method = "GET" ; webReq. Timeout = _to ; string respText ; try { string page ; using ( WebResponse resp = webReq. GetResponse ( ) ) using ( Stream respS = resp. GetResponseStream ( ) ) using ( StreamReader sr = new StreamReader ( respS ) ) page = sr. ReadToEnd ( ) ; Log. Trace ( "Response page:`{0}'" , page ) ; return page ; } catch ( Exception err ) { Log. Warn ( "Request for uri:`{0}' exception: {1}" , uri, err. Message ) ; throw ; } }

private static Logger Log = LogManager. GetCurrentClassLogger ( ) ; <br/>
<br/>
public string Request ( string cmd, string getParams ) <br/>
{ <br/>
Uri uri = new Uri ( _baseUri, cmd + "?" + getParams ) ; <br/>
Log. Debug ( "Request for uri:`{0}'" , uri ) ; <br/>
HttpWebRequest webReq = ( HttpWebRequest ) WebRequest. Create ( uri ) ; <br/>
webReq. Method = "GET" ; <br/>
webReq. Timeout = _to ; <br/>
<br/>
string respText ; <br/>
try <br/>
{ <br/>
string page ; <br/>
using ( WebResponse resp = webReq. GetResponse ( ) ) <br/>
using ( Stream respS = resp. GetResponseStream ( ) ) <br/>
using ( StreamReader sr = new StreamReader ( respS ) ) <br/>
page = sr. ReadToEnd ( ) ; <br/>
Log. Trace ( "Response page:`{0}'" , page ) ; <br/>
return page ; <br/>
} <br/>
catch ( Exception err ) <br/>
{ <br/>
Log. Warn ( "Request for uri:`{0}' exception: {1}" , uri, err. Message ) ; <br/>
throw ; <br/>
} <br/>
}

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

सामान्य तौर पर, वर्तमान त्रुटि हैंडलर में उस संदर्भ का विस्तार करना उपयोगी होता है जो अपवाद के अपवाद और विशिष्ट विशेषताओं के लिए नेतृत्व करता है। उदाहरण में, WebException मामले के लिए स्थिति फ़ील्ड प्रदर्शित करना उपयोगी होगा।

सुरक्षा उपायों को लॉग करें

NLog की कुछ ऑटो-लॉगिंग क्षमताओं के बावजूद, इस बात की कोई गारंटी नहीं है कि प्रक्रिया के अंत में लॉग सुरक्षित है।

दिलचस्प है, AppDomain.ProcessExit इवेंट को संसाधित करके रिकॉर्डिंग को पूरा करने का प्रयास पूरी तरह से सही नहीं है। नेटवर्क पर लॉग सहित लिखने के लिए कॉन्फ़िगरेशन को कई अलग-अलग तरीकों से कॉन्फ़िगर किया जा सकता है। और इस घटना का हैंडलर एक सीमित वातावरण में है। .Net में, यह रन टाइम 2 सेकंड से अधिक नहीं है, जबकि मोनो में यह एक थ्रेडपूल है । इसलिए, अधिक अनुकूल वातावरण में प्रक्रिया को पूरा करने का ध्यान रखना उपयोगी है।

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

private static readonly Logger Log = LogManager. GetCurrentClassLogger ( ) ; public static void Main ( string [ ] args ) { AppDomain. CurrentDomain . UnhandledException += OnUnhandledException ; ( ... ) LogManager. Flush ( ) ; } static void OnUnhandledException ( object sender, UnhandledExceptionEventArgs e ) { Log. Fatal ( "Unhandled exception: {0}" , e. ExceptionObject ) ; LogManager. Flush ( ) ; }

private static readonly Logger Log = LogManager. GetCurrentClassLogger ( ) ; <br/>
<br/>
public static void Main ( string [ ] args ) <br/>
{ <br/>
AppDomain. CurrentDomain . UnhandledException += OnUnhandledException ; <br/>
( ... ) <br/>
LogManager. Flush ( ) ; <br/>
} <br/>
<br/>
static void OnUnhandledException ( object sender, UnhandledExceptionEventArgs e ) <br/>
{ <br/>
Log. Fatal ( "Unhandled exception: {0}" , e. ExceptionObject ) ; <br/>
LogManager. Flush ( ) ; <br/>
}

इसके अलावा, आपको LogManager.Flush () को कॉल करना चाहिए जहां भी प्रक्रिया समाप्ति संभव है। सभी गैर-पृष्ठभूमि थ्रेड्स के अंत में।

यदि आपका आवेदन एक जीत-सेवा या Asp.Net है, तो आपको कोड के संबंधित आरंभ और अंत की घटनाओं को संसाधित करना चाहिए।

कितना लॉग इन करना है

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

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

लॉगिंग स्तरों की गुणात्मक रचना का पहले से ही पिछले लेख में विश्लेषण किया गया है, यहां हम केवल मात्रात्मक रचना पर विचार करते हैं:

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

मुकाबला तैनाती है

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

मैं केवल फाइलों के शब्दार्थ संगठन पर ध्यान केन्द्रित करूंगा। उन्हें 3 समूहों में विभाजित किया जाना चाहिए। मॉड्यूल लॉग को अलग-अलग फ़ाइलों में अलग करना आवश्यक हो सकता है, लेकिन अब से मैं अभी भी प्रत्येक समूह के लिए एक फ़ाइल के बारे में बात करूंगा।

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

यदि आवेदन सफलतापूर्वक लागू किया जाता है, तो केवल पहले दो समूह संचालन में रहते हैं।

क्रैश जांच

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

लॉग एसिंक्रोनस के लिए आउटपुट बनाना वांछनीय है।
उदाहरण, मुकाबला सेटिंग्स।

<nlog autoReload = "true" > <targets > <target name = "fileInfo" type = "AsyncWrapper" queueLimit = "5000" overflowAction = "Block" > <target type = "File" fileName = "${basedir}/logs/info.log" /> </target > <target name = "fileWarn" type = "AsyncWrapper" queueLimit = "5000" overflowAction = "Block" > <target type = "File" fileName = "${basedir}/logs/warn.log" /> </target > </targets > <rules > <logger name = "*" minlevel = "Info" writeTo = "fileInfo" /> <logger name = "*" minlevel = "Warn" writeTo = "fileWarn" /> </rules > </nlog >

<nlog autoReload = "true" > <br/>
<targets > <br/>
<target name = "fileInfo" type = "AsyncWrapper" queueLimit = "5000" overflowAction = "Block" > <br/>
<target type = "File" fileName = "${basedir}/logs/info.log" /> <br/>
</target > <br/>
<target name = "fileWarn" type = "AsyncWrapper" queueLimit = "5000" overflowAction = "Block" > <br/>
<target type = "File" fileName = "${basedir}/logs/warn.log" /> <br/>
</target > <br/>
</targets > <br/>
<br/>
<rules > <br/>
<logger name = "*" minlevel = "Info" writeTo = "fileInfo" /> <br/>
<logger name = "*" minlevel = "Warn" writeTo = "fileWarn" /> <br/>
</rules > <br/>
</nlog >

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

लकड़हारे के साथ क्या नहीं करना चाहिए

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

कारण जो भी हो, हमें यह याद रखना चाहिए कि पहली जगह में, ऐसी सुविधाएं पूरी तरह से कंपाइलर को अनुकूलन की संभावना को मार देती हैं।

फ़िल्टर के साथ भी, उपयोगकर्ता को सीधे लकड़हारा जानकारी प्रदर्शित करना आवश्यक नहीं है। समस्या यह है कि यह जानकारी कार्यक्रम की आंतरिक संरचना पर निर्भर करती है। यह संभावना नहीं है कि आप रिफैक्टरिंग की प्रक्रिया में लकड़हारा के उत्पादन को बचाने की कोशिश कर रहे हैं। शायद, यह सिर्फ सोचने और कार्यक्षमता साझा करने के लायक है। शायद परियोजना को केवल लॉगिंग के दूसरे स्तर की आवश्यकता होती है। इस मामले में, लकड़हारा के ऊपर रैपर सिर्फ सही चीज होगी।

मुझे NLog से क्या याद आ रहा है?

लंबर फ़ंक्शंस की कक्षाएं बनाने से बचने के लिए लकड़हारा विधियों का अतिरिक्त अधिभार । मैं फॉर्म की कॉल करना चाहता हूं
लॉग.ट्रेस <TArg1, TArg2> (फंक <TArg1, TArg2, string> messageCustrator, TArg1 arg1, TArg2 arg2)
लेकिन इस समय, सबसे छोटे मानव पठनीय विकल्प में छिपी हुई कक्षा पीढ़ी शामिल है:
Log.Trace () => MessageCreate (arg1, arg2))
बाइनरी संगतता विभिन्न प्लेटफार्मों पर सेवाओं का त्वरित परीक्षण करने में मदद करता है। NLog में प्लेटफॉर्म के आधार पर बहुत सारे सशर्त संकलन निर्देश हैं। यानी मोनो के लिए बाइनरी अप्रत्याशित रूप से डॉटनेट में काम कर सकता है। और एक सीमित कॉन्फ़िगरेशन में भले ही भविष्यवाणी करना बहुत वांछनीय हो।
सशर्त विस्तार। यह स्पष्ट है कि द्विआधारी संगतता के साथ आपको कार्यक्षमता का त्याग करना होगा, लेकिन हमारे पास पहले से ही एक सुविधाजनक विस्तार तंत्र है। जो कुछ भी शेष है, वह प्लेटफॉर्म के आधार पर एक्सटेंशन को फ़िल्टर करने के लिए है। पिछली विशेषता के साथ, यह IL-binaries के साथ निर्देशिका की प्रतिलिपि बनाकर एक सरल परिनियोजन भी प्रदान करता है।
एक सामान्य संदर्भ में आंतरिक संदेश लॉग करना। सिस्टम में बनाई गई लॉगर्स की एक सूची उपयोगी होगी। दुर्भाग्य से, मुझे यकीन नहीं है कि पुनरावृत्ति से बचा जा सकता है। उदाहरण के लिए, जब किसी फाइल का आउटपुट अपने आप आउटपुट एरर्स लिखना शुरू करता है।

NLog, Log4Net, एंटरप्राइज लाइब्रेरी, स्मार्टइंस्पेक्ट ...

आपस में लकड़हारे की विभिन्न तुलनाएं एक महत्वपूर्ण विवरण को याद करती हैं।
न केवल सीमाओं / अवसरों की तुलना करना महत्वपूर्ण है, बल्कि अपनी इच्छा सूची को जल्दी से जोड़ने की क्षमता भी है।

इसलिए, मैं अभी के लिए NLog के साथ दोस्त बनूंगा।
मैं तुम्हें क्या चाहता हूँ?

लॉग आर्किटेक्चर