लॉगिंग के लिए प्रासंगिक जानकारी का संग्रह

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

समस्या का बयान

मान लीजिए कि हमारे पास ASP.NET MVC वी सर्विस है। यह POST अनुरोधों को स्वीकार करता है जिसमें JSON प्रारूप में किए जाने की आवश्यकता होती है। इस तरह के विवरण का विश्लेषण करने के बाद, सेवा डेटाबेस में कई एसक्यूएल प्रश्नों का निर्माण और निष्पादन करती है। वह फिर परिणामों को जोड़ती है और उन्हें क्लाइंट को भेजती है।

यह कहा जाना चाहिए कि यह सेवा एसिंक्रोनस का व्यापक उपयोग करती है और एसिंक्स्ट / वेट और Task माध्यम से मल्टीथ्रेडिंग करती है।

अब जब हम समझते हैं कि हम किसके साथ काम कर रहे हैं, तो चलिए समस्याओं की ओर बढ़ते हैं।

प्रासंगिक त्रुटि जानकारी एकत्रित करना

कभी-कभी हमारी सेवा त्रुटियां देती है। कारण अलग-अलग हो सकते हैं: गलत इनपुट JSON, कोड में बग, डेटाबेस के साथ समस्या ... इस मामले में, हमें लॉग में त्रुटि जानकारी लिखनी चाहिए।

अपवाद को लॉग करने में कोई समस्या नहीं है। हम इसे अपने नियंत्रक की क्रिया विधि में पकड़ सकते हैं:

 public class ServiceController : ApiController { [Route("api/service")] [HttpPost] public async Task<HttpResponseMessage> ServiceAction( [FromBody] RequestModel requestModel ) { try { ... } catch (Exception ex) { Logger.LogError(ex); throw; } } } 

या हम इसके लिए एक विशेष विशेषता बना सकते हैं:

 public class LogErrorAttribute : ActionFilterAttribute { public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext) { base.OnActionExecuted(actionExecutedContext); if (actionExecutedContext.Exception != null) { Logger.LogError(actionExecutedContext.Exception); } } } 

और इसका प्रयोग क्रिया विधि पर करें:

 [Route("api/service")] [HttpPost] [LogError] public async Task<HttpResponseMessage> ServiceAction( [FromBody] RequestModel requestModel ) { ... } 

लेकिन हमें और चाहिए। प्रत्येक त्रुटि के लिए, हम अतिरिक्त जानकारी संग्रहीत करना चाहते हैं:

• अनुरोध के JSON निकाय का पाठ।
• सभी उत्पन्न एसक्यूएल प्रश्नों का पाठ।

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

अनुरोध शरीर के लिए ऐसा करना मुश्किल नहीं है:

 public class ServiceController : ApiController { [Route("api/service")] [HttpPost] public async Task<HttpResponseMessage> ServiceAction( [FromBody] RequestModel requestModel ) { var requestText = await Request.Content.ReadAsStringAsync(); try { ... } catch (Exception ex) { Logger.LogError(ex); Logger.LogError($"Request test is {requestText}"); throw; } } } 

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

एक विकल्प संदेशों की सूची का उपयोग करना है (उदा। List<string> )। हम इसे अपने एक्शन मेथड ( ServiceAction ) में बनाते हैं और इसे उस तरीके से पास करते हैं जो SQL उत्पन्न करता है। वहां हम इस सूची में SQL क्वेरी पाठ जोड़ देंगे। यदि कोई त्रुटि उत्पन्न होती है, तो कार्रवाई विधि में संदेशों की एक सूची होगी, जिसे लॉग में रखा जाना चाहिए।

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

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

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

 public static async Task<SqlDataReader> RunReaderAsync(this SqlCommand cmd) { var message = $"SQL Server query is: {cmd.CommandText}"; ErrorContext.Current.AttachMessage(message); ... } 

यहां एक गंभीर समस्या है। हमारी सेवा एक साथ कई अनुरोधों को पूरा कर सकती है। और इस तरह के प्रत्येक अनुरोध में संदेशों की अपनी सूची होनी चाहिए। इसके अलावा, एक ही अनुरोध को संसाधित करते समय, हमारा कोड कई थ्रेड्स (उदाहरण के लिए, async / प्रतीक्षा का उपयोग करके) को स्पॉन कर सकता है। और इन सभी थ्रेड्स के पास एक ही संदेश सूची तक पहुंच होनी चाहिए। इसे कैसे लागू किया जा सकता है?

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

आइए ErrorContext वर्ग के कार्यान्वयन को ErrorContext :

 public class ErrorContext { private static readonly object Lock = new object(); private static readonly AsyncLocal<ErrorContext> CurrentErrorContext = new AsyncLocal<ErrorContext>(); private readonly Lazy<ConcurrentBag<string>> _attachedMessages = new Lazy<ConcurrentBag<string>>(() => new ConcurrentBag<string>()); private ErrorContext() {} public static ErrorContext Current { get { lock (Lock) { var errorContext = CurrentErrorContext.Value; if (errorContext == null) { CurrentErrorContext.Value = errorContext = new ErrorContext(); } return errorContext; } } } public static ErrorContext CreateNewErrorContext() { lock (Lock) { var errorContext = new ErrorContext(); CurrentErrorContext.Value = errorContext; return errorContext; } } public void AttachMessage(string message) { if (!string.IsNullOrWhiteSpace(message)) { _attachedMessages.Value.Add(message); } } public IReadOnlyList<string> GetMessages() { return _attachedMessages.Value.ToArray(); } } 

CreateNewErrorContext विधि तुरंत एक नई संदेश सूची बनाती है और इसे CurrentErrorContext फ़ील्ड में CurrentErrorContext , जो कि AsyncLocal प्रकार का है। आप स्थिर संपत्ति Current का उपयोग करके कोड में कहीं भी वर्तमान सूची तक पहुंच सकते हैं। AttachMessage पद्धति सूची में एक नया संदेश जोड़ती है। यह ConcurrentBag एक उदाहरण में संदेशों को संग्रहीत करता है, क्योंकि यह विधि एक ही समय में कई थ्रेड्स से कॉल की जा सकती है। GetMessages पद्धति सभी सहेजे गए संदेशों को लौटाती है, ताकि उन्हें लॉग में लिखा जा सके।

अब आप आसानी से आरंभ कर सकते हैं और ErrorContext अंदर LogErrorAttribute उपयोग कर सकते हैं:

 public class LogErrorAttribute : ActionFilterAttribute { public override void OnActionExecuting(HttpActionContext actionContext) { ErrorContext.CreateNewErrorContext(); base.OnActionExecuting(actionContext); } public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext) { base.OnActionExecuted(actionExecutedContext); if (actionExecutedContext.Exception != null) { foreach(var message in ErrorContext.Current.GetMessages()) { Logger.LogError(message); } Logger.LogError(actionExecutedContext.Exception); } } } 

आपके कोड में कहीं भी, आप वर्तमान त्रुटि संदर्भ में अपना संदेश इस प्रकार जोड़ सकते हैं:

 ErrorContext.Current.AttachMessage(message); 

प्रदर्शन लॉगिंग

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

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

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

इसके अतिरिक्त, मुझे त्रुटियों के लिए समान जानकारी की आवश्यकता है। समस्या को पुन: उत्पन्न करने में सक्षम होने के लिए मुझे एक अनुरोध निकाय की आवश्यकता है। मुझे एसक्यूएल प्रश्नों के पाठ की आवश्यकता होती है, जब वे सबसे लंबा समय लेते हैं।

यह कैसे प्राप्त किया जा सकता है? फिर से, AsyncLocal वर्ग का उपयोग कर:

 public class Timer : IDisposable { private static readonly object Lock = new object(); private static readonly AsyncLocal<Timer> CurrentTimer = new AsyncLocal<Timer>(); private readonly Stopwatch _stopwatch = new Stopwatch(); private readonly Lazy<ConcurrentQueue<Timer>> _attachedTimers = new Lazy<ConcurrentQueue<Timer>>(() => new ConcurrentQueue<Timer>()); private readonly Lazy<ConcurrentQueue<string>> _attachedMessages = new Lazy<ConcurrentQueue<string>>(() => new ConcurrentQueue<string>()); private readonly string _description; private readonly TimeSpan? _threshold; private readonly Timer _previousCurrent; private bool _isDisposed; private bool _suspendLogging; private Timer(Timer previousCurrent, string description = null, TimeSpan? threshold = null) { _previousCurrent = previousCurrent; _description = description; _threshold = threshold; _stopwatch.Start(); } public static Timer Current { get { lock (Lock) { var timer = CurrentTimer.Value; if (timer == null) { CurrentTimer.Value = timer = new Timer(null); } return timer; } } } public static Timer SetCurrentTimer(string description, TimeSpan? threshold = null) { lock (Lock) { var currentTimer = CurrentTimer.Value; var timer = new Timer(currentTimer, description, threshold); CurrentTimer.Value = timer; currentTimer?._attachedTimers.Value.Enqueue(timer); return timer; } } public void AttachMessage(string message) { if (!string.IsNullOrWhiteSpace(message)) { _attachedMessages.Value.Enqueue(message); } } public void Dispose() { if (!_isDisposed) { _isDisposed = true; _stopwatch.Stop(); if (_attachedTimers.IsValueCreated) { foreach (var attachedTimer in _attachedTimers.Value) { attachedTimer.Dispose(); } } if (!_suspendLogging && _threshold.HasValue && _stopwatch.Elapsed > _threshold.Value) { Log(); } if (_previousCurrent != null) { CurrentTimer.Value = _previousCurrent; } } } private JObject Message { get { Dispose(); var message = new StringBuilder($"It took {_stopwatch.ElapsedMilliseconds} ms to execute {_description}."); if (_threshold.HasValue) { message.Append($" Duration threshold is {_threshold.Value.TotalMilliseconds} ms."); } var messageObj = new JObject { ["message"] = message.ToString(), }; if (_attachedTimers.IsValueCreated && _attachedTimers.Value.Any()) { messageObj["attachedTimers"] = new JArray(_attachedTimers.Value.Select(t => t.Message)); } if (_attachedMessages.IsValueCreated && _attachedMessages.Value.Any()) { messageObj["attachedMessages"] = new JArray(_attachedMessages.Value); } return messageObj; } } public void Log() { try { _suspendLogging = true; Dispose(); if (_stopwatch.Elapsed < _threshold) { Logger.LogDebug(Message.ToString()); } else { Logger.LogWarning(Message.ToString()); } } finally { _suspendLogging = false; } } } 

आइए देखें कि यह कैसे काम करता है। SetCurrentTimer विधि एक नया टाइमर बनाता है। यहां आप इसके विवरण और एक वैकल्पिक रन-टाइम सीमा को निर्दिष्ट कर सकते हैं।

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

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

 using (Timer.SetCurrentTimer("The whole block")) { ... using (Timer.SetCurrentTimer("Part 1")) { ... } ... using (Timer.SetCurrentTimer("Part 2")) { ... } ... } 

Current संपत्ति वर्तमान टाइमर तक पहुंच प्रदान करती है। यदि आप इसमें कुछ संदेश जोड़ना चाहते हैं तो यह उपयोगी है:

 var message = $"SQL Server query is: {cmd.CommandText}"; Timer.Current.AttachMessage(message); 

यहाँ, संलग्न संदेश और नेस्टेड टाइमर ConcurrentQueue उदाहरणों में संग्रहीत हैं, क्योंकि उनका क्रम महत्वपूर्ण हो सकता है।

Message प्रॉपर्टी करंट से इकठ्ठा की गई यूनिट में जमा किए गए Message लौटा देती है और सभी टाइमर उसमें ढेर हो जाते हैं। यहाँ मैं JSON.NET लाइब्रेरी से JSON क्लासेस का उपयोग करके सभी संदेशों की संरचना करता हूँ। लेकिन वास्तव में यह इतना महत्वपूर्ण नहीं है। आप किसी भी प्रारूप का उपयोग कर सकते हैं।

Log विधि टाइमर में लॉग करने के लिए संग्रहीत जानकारी लिखती है, भले ही रन-टाइम थ्रेशोल्ड सेट किया गया है या नहीं। उसी समय, Dispose विधि लॉग को जानकारी लिखती है केवल अगर सेट रनटाइम थ्रेशोल्ड पार हो गया हो।

अब हम अपने नियंत्रकों के तरीकों के लिए एक और विशेषता बना सकते हैं:

 public class TimerContextAttribute : ActionFilterAttribute { private readonly string _timerDescription; private readonly int _durationThresholdMs; private readonly AsyncLocal<Timer> _timer = new AsyncLocal<Timer>(); public TimerContextAttribute(string timerDescription, int durationThresholdMs) { if (string.IsNullOrWhiteSpace(timerDescription)) throw new ArgumentNullException(nameof(timerDescription)); _timerDescription = timerDescription; _durationThresholdMs = durationThresholdMs; } public override void OnActionExecuting(HttpActionContext actionContext) { _timer.Value = Timer.SetCurrentTimer(_timerDescription, TimeSpan.FromMilliseconds(_durationThresholdMs)); base.OnActionExecuting(actionContext); } public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext) { base.OnActionExecuted(actionExecutedContext); _timer.Value?.Dispose(); } } 

और इसे इस तरह एक्शन तरीकों पर प्रयोग करें:

 [Route("api/service")] [HttpPost] [TimerContext("For ServiceAction method", 3000)] public async Task<HttpResponseMessage> ServiceAction( [FromBody] RequestModel requestModel ) { ... } 

निष्कर्ष

इस लेख में, मैंने वर्णन किया कि कोड में कई स्थानों से जानकारी एकत्र करना और बाद में इसे एक्सेस करना कितना सरल है। ऐसी कार्यक्षमता को स्थिर गुणों और विधियों का उपयोग करके लागू किया जा सकता है जो AsyncLocal वर्ग के उदाहरणों में हेरफेर करते हैं।

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