प्रत्येक अनुरोध के लिए अलग लॉगिंग स्तर

ThoughtWorks Technology Radar को पढ़ते हुए, मैंने " रिक्वेस्ट लॉगिंग प्रति अनुरोध " तकनीक पर ठोकर खाई। हम कन्फर्मिट में लॉगिंग का व्यापक उपयोग करते हैं, और मुझे आश्चर्य है कि इस कार्यक्षमता को कैसे लागू किया जा सकता है।

समस्या का वर्णन

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

हम समस्या के कारण को समझने के लिए अपने कोड में पर्याप्त लॉगिंग निर्देश डाल सकते हैं। ये निर्देश आमतौर पर आपके संदेश को एक निश्चित लॉग स्तर (डीबग, सूचना, चेतावनी, ...) के साथ मेल खाते हैं। इसके अलावा, लॉग का अपना स्तर भी होता है। लॉग स्तर से ऊपर के स्तर वाले सभी संदेश लॉग स्टोरेज (फ़ाइल, डेटाबेस, ...) में दर्ज किए जाएंगे। यदि संदेश स्तर लॉग स्तर से कम है, तो संदेश बस त्याग दिया जाएगा।

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

प्रति आवेदन लॉगिंग का एक स्तर

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

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

ईमानदारी से, ये कठिनाइयाँ दुर्गम नहीं हैं। "बुरे" अनुरोधों के संदेशों से "अच्छे" अनुरोधों के संदेशों को अलग करने के लिए, आप सहसंबंध आईडी का उपयोग कर सकते हैं। सभी आधुनिक लॉग प्रोसेसिंग सिस्टम इस सहित विभिन्न मानदंडों द्वारा रिकॉर्ड को फ़िल्टर करने की अनुमति देते हैं।

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

और डिस्क स्थान अब अपेक्षाकृत सस्ता है, इसलिए बहुत सारे रिकॉर्ड संग्रहीत करना कोई समस्या नहीं है। खासकर यदि हम समय-समय पर पुराने रिकॉर्ड्स को हटा सकते हैं।

हालाँकि, क्या हम इस प्रणाली में सुधार कर सकते हैं? क्या हम कुछ शर्तों के आधार पर, प्रत्येक अनुरोध के लिए एक अलग लॉगिंग स्तर सेट कर सकते हैं? मैं यहां इस समस्या पर विचार करना चाहूंगा।

प्रत्येक अनुरोध के लिए अलग लॉगिंग स्तर

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

इसलिए, कार्य निर्धारित है। चलिए शुरू करते हैं।

मैं .NET कोर पर आधारित एक साधारण वेब सेवा बनाऊंगा। उसके पास एक एकल नियंत्रक होगा:

[Route("api/[controller]")] [ApiController] public class ValuesController : ControllerBase { ... // GET api/values [HttpGet] public ActionResult<IEnumerable<string>> Get() { Logger.Info("Executing Get all"); return new[] { "value1", "value2" }; } // GET api/values/5 [HttpGet("{id}")] public ActionResult<string> Get(int id) { Logger.Info($"Executing Get {id}"); return "value"; } } 

हम बाद में लकड़हारे की संपत्ति के कार्यान्वयन पर चर्चा करेंगे। इस एप्लिकेशन के लिए मैं लॉगिंग के लिए log4net लाइब्रेरी का उपयोग करूंगा। यह पुस्तकालय एक दिलचस्प अवसर प्रदान करता है। मैं लेवल इनहेरिटेंस की बात कर रहा हूं । संक्षेप में, यदि इस लाइब्रेरी के कॉन्फ़िगरेशन में आप कहते हैं कि X नाम के साथ लॉग में Info लॉगिंग स्तर होना चाहिए, तो इसका मतलब है कि X के साथ शुरू होने वाले नामों के साथ सभी लॉग (उदाहरण के लिए, XY , XZ , XAB ) इस समान स्तर का वारिस करेंगे।

यहां से मूल विचार आता है। प्रत्येक अनुरोध के लिए, मैं किसी तरह लॉगिंग के आवश्यक स्तर का निर्धारण करूंगा। फिर मैं log4net कॉन्फ़िगरेशन में एक नया नाम लॉग बनाऊंगा । इस लॉग में आवश्यक लॉगिंग स्तर होगा। उसके बाद, वर्तमान अनुरोध के हिस्से के रूप में बनाई गई सभी लकड़हारा वस्तुओं में मेरे द्वारा बनाए गए इस नए लॉग के नाम से शुरू होने वाले नाम होने चाहिए। यहाँ एकमात्र समस्या यह है कि log4net लॉग को कभी नहीं हटाता है। एक बार बनाए जाने के बाद, वे जीवन भर लागू होते हैं। इस कारण से, मैं शुरू में लॉगिंग के प्रत्येक संभावित स्तर के लिए एक लॉग बनाता हूं:

 <?xml version="1.0" encoding="utf-8" ?> <log4net> <appender name="Console" type="log4net.Appender.ConsoleAppender"> <layout type="log4net.Layout.PatternLayout"> <!-- Pattern to output the caller's file name and line number --> <conversionPattern value="%5level [%thread] (%file:%line) - %message%newline" /> </layout> </appender> <appender name="RollingFile" type="log4net.Appender.RollingFileAppender"> <file value="RequestLoggingLog.log" /> <appendToFile value="true" /> <maximumFileSize value="100KB" /> <maxSizeRollBackups value="2" /> <layout type="log4net.Layout.PatternLayout"> <conversionPattern value="%level %thread %logger - %message%newline" /> </layout> </appender> <root> <level value="WARN" /> <appender-ref ref="Console" /> <appender-ref ref="RollingFile" /> </root> <logger name="EdlinSoftware.Log.Error"> <level value="ERROR" /> </logger> <logger name="EdlinSoftware.Log.Warning"> <level value="WARN" /> </logger> <logger name="EdlinSoftware.Log.Info"> <level value="INFO" /> </logger> <logger name="EdlinSoftware.Log.Debug"> <level value="DEBUG" /> </logger> </log4net> 

अब मेरे पास EdlinSoftware.Log.XXXX नाम के साथ कई लॉग हैं। ये नाम प्रश्नों में प्रयुक्त लॉग नामों के उपसर्गों के रूप में काम करेंगे। अनुरोधों के बीच टकराव से बचने के लिए, मैं इस अनुरोध के लिए एक AsyncLocal उदाहरण में परिकलित उपसर्ग संग्रहीत करूंगा । इस वस्तु का मूल्य नए OWIN मिडलवेयर में सेट किया जाएगा:

 app.Use(async (context, next) => { try { LogSupport.LogNamePrefix.Value = await LogSupport.GetLogNamePrefix(context); await next(); } finally { LogSupport.LogNamePrefix.Value = null; } }); 

जब यह मान सेट हो जाता है, तो वांछित नाम उपसर्ग के साथ लकड़हारा बनाना बहुत आसान है:

 public static class LogSupport { public static readonly AsyncLocal<string> LogNamePrefix = new AsyncLocal<string>(); public static ILog GetLogger(string name) { return GetLoggerWithPrefixedName(name); } public static ILog GetLogger(Type type) { return GetLoggerWithPrefixedName(type.FullName); } private static ILog GetLoggerWithPrefixedName(string name) { if (!string.IsNullOrWhiteSpace(LogNamePrefix.Value)) { name = $"{LogNamePrefix.Value}.{name}"; } return LogManager.GetLogger(typeof(LogSupport).Assembly, name); } .... } 

अब यह स्पष्ट है कि हमारे नियंत्रक में लकड़हारा उदाहरण कैसे प्राप्त करें:

 [Route("api/[controller]")] [ApiController] public class ValuesController : ControllerBase { private ILog _logger; private ILog Logger { get => _logger ?? (_logger = LogSupport.GetLogger(typeof(ValuesController))); } .... } 

यह केवल एक ही काम करने के लिए बना हुआ है: किसी भी तरह से उन नियमों को निर्धारित करें जिनके द्वारा हम प्रत्येक अनुरोध के लिए लॉगिंग का स्तर चुनते हैं। यह एक काफी लचीला तंत्र होना चाहिए। मूल विचार C # स्क्रिप्टिंग का उपयोग करना है। मैं एक LogLevelRules.json फ़ाइल बनाऊंगा , जहां मैं "नियम - लॉगिंग स्तर" जोड़े के एक सेट को परिभाषित करूंगा:

 [ { "logLevel": "Debug", "ruleCode": "context.Request.Path.Value == \"/api/values/1\"" }, { "logLevel": "Debug", "ruleCode": "context.Request.Path.Value == \"/api/values/3\"" } ] 

यहां लॉगलेव लॉगिंग का वांछित स्तर है, और नियम कोड सी # कोड है जो दिए गए अनुरोध के लिए बूलियन मान लौटाता है। एप्लिकेशन एक-एक करके नियम कोड चलाएगा। पहला नियम, जिसका कोड सही है, का उपयोग लॉगिंग के उचित स्तर को निर्धारित करने के लिए किया जाएगा। यदि सभी नियम झूठे हैं, तो डिफ़ॉल्ट स्तर का उपयोग किया जाएगा।

नियमों का एक स्ट्रिंग प्रतिनिधित्व से प्रतिनिधि बनाने के लिए, CSharpScript वर्ग का उपयोग किया जाता है :

 public class Globals { public HttpContext context; } internal class LogLevelRulesCompiler { public IReadOnlyList<LogLevelRule> Compile(IReadOnlyList<LogLevelRuleDescription> levelRuleDescriptions) { var result = new List<LogLevelRule>(); foreach (var levelRuleDescription in levelRuleDescriptions ?? new LogLevelRuleDescription[0]) { var script = CSharpScript.Create<bool>(levelRuleDescription.RuleCode, globalsType: typeof(Globals)); ScriptRunner<bool> runner = script.CreateDelegate(); result.Add(new LogLevelRule(levelRuleDescription.LogLevel, runner)); } return result; } } internal sealed class LogLevelRule { public string LogLevel { get; } public ScriptRunner<bool> Rule { get; } public LogLevelRule(string logLevel, ScriptRunner<bool> rule) { LogLevel = logLevel ?? throw new ArgumentNullException(nameof(logLevel)); Rule = rule ?? throw new ArgumentNullException(nameof(rule)); } } 

यहाँ, संकलन विधि LogLevelRules.json फ़ाइल से पढ़ी गई वस्तुओं की सूची को पुनः प्राप्त करती है। यह प्रत्येक नियम के लिए एक धावक प्रतिनिधि बनाता है।

इस प्रतिनिधि सूची को बचाया जा सकता है:

 LogSupport.LogLevelSetters = new LogLevelRulesCompiler().Compile( new LogLevelRulesFileReader().ReadFile("LogLevelRules.json") ); 

और भविष्य में इस्तेमाल किया:

 public static class LogSupport { internal static IReadOnlyList<LogLevelRule> LogLevelSetters = new LogLevelRule[0]; ... public static async Task<string> GetLogNamePrefix(HttpContext context) { var globals = new Globals { context = context }; string result = null; foreach (var logLevelSetter in LogLevelSetters) { if (await logLevelSetter.Rule(globals)) { result = $"EdlinSoftware.Log.{logLevelSetter.LogLevel}"; break; } } return result; } } 

इस प्रकार, जब आवेदन शुरू होता है, हम LogLevelRules.json को पढ़ते हैं, इसकी सामग्री को CSharpScript वर्ग का उपयोग करके प्रतिनिधि सूची में परिवर्तित करते हैं, और इस सूची को LogSupport.LogLevelSetters क्षेत्र में सहेजते हैं। फिर, प्रत्येक अनुरोध के लिए, हम लॉगिंग स्तर प्राप्त करने के लिए इस सूची से प्रतिनिधियों को चलाते हैं।

केवल करने के लिए बचा है LogLevelRules.json फ़ाइल में परिवर्तन ट्रैक करना है। यदि हम कुछ प्रश्नों के लिए लॉगिंग स्तर सेट करना चाहते हैं, तो हम इस फ़ाइल में एक नया नियम जोड़ते हैं। हमारे आवेदन को फिर से शुरू किए बिना इन परिवर्तनों को लागू करने के लिए मजबूर करने के लिए, फ़ाइल की निगरानी करना आवश्यक है:

 var watcher = new FileSystemWatcher { Path = Directory.GetCurrentDirectory(), Filter = "*.json", NotifyFilter = NotifyFilters.LastWrite }; watcher.Changed += (sender, eventArgs) => { // ,  ,  ,   . Thread.Sleep(1000); LogSupport.LogLevelSetters = new LogLevelRulesCompiler().Compile( new LogLevelRulesFileReader().ReadFile("LogLevelRules.json") ); }; watcher.EnableRaisingEvents = true; 

यह ध्यान दिया जाना चाहिए कि संक्षिप्तता के लिए, मैं LogSupport.LogLevelSetters क्षेत्र के साथ काम करते समय स्ट्रीम सिंक्रनाइज़ेशन कोड को छोड़ देता हूं। लेकिन व्यवहार में, ऐसे सिंक्रनाइज़ेशन की आवश्यकता होती है।

पूर्ण आवेदन कोड GitHub पर पाया जा सकता है ।

कमियों

ऊपर दिखाया गया कोड आपको प्रत्येक अनुरोध के लिए एक अलग लॉगिंग स्तर सेट करने की समस्या को हल करने की अनुमति देता है। लेकिन उसके पास कमियों की संख्या है। आइए उनकी चर्चा करें।

1. यह अप्रोच लॉग्स के नाम को बदल देता है। इसलिए, " MyClassLogger " के बजाय, " Edlinsoft.Log.Debug.MyClassLogger " जैसी चीज़ को लॉग रिपॉजिटरी में संग्रहीत किया जाएगा। आप इसके साथ रह सकते हैं, लेकिन यह बहुत सुविधाजनक नहीं है। शायद लॉग (लॉग लेआउट) के लेआउट को बदलकर समस्या को दूर किया जा सकता है।

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

3. वर्णित दृष्टिकोण लॉगर के कई उदाहरण बनाता है। इसके निर्माण के दौरान और कचरा संग्रहण के दौरान मेमोरी और प्रोसेसर साइकिल दोनों की खपत होती है। आपके आवेदन के आधार पर, यह एक महत्वपूर्ण मुद्दा हो सकता है या नहीं भी हो सकता है।

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

• प्रतिनिधियों में नियम कोड के लिए संकलन समय त्रुटियों।
• इन प्रतिनिधियों की रनटाइम त्रुटियाँ।

किसी तरह हमें इन त्रुटियों के बारे में पता लगाने की आवश्यकता है, अन्यथा हमारी लॉगिंग केवल काम नहीं करेगी, और हमें इसके बारे में पता भी नहीं होगा।

5. JSON फ़ाइल में नियम कोड, सिद्धांत रूप में, कोई भी निर्देश हो सकता है। यह संभावित रूप से सुरक्षा मुद्दों को जन्म दे सकता है। किसी तरह इस कोड की क्षमताओं को सीमित करना आवश्यक है। दूसरी ओर, यदि कोई हमलावर सीधे आपके एप्लिकेशन की फ़ाइलों को लिखने में सक्षम है, तो सुरक्षा समस्या स्पष्ट है।

निष्कर्ष

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