با استفاده از log اطلاعاتی را که هنگام بروز مشکل در برنامه بتوان برای رفع ایراد از آنها کمک گرفت، ثبت می کنیم.
نوشتن لاگ چه دست آوردی برای تیم توسعه دارد؟
اگر به درستی در برنامه خود لاگ ها را ثبت کرده باشید معمولا مشکلات پیش آمده در محیط پروداکشن را در کمتر از 5 دقیقه می توانید تشخیص دهید.
اما اگر ثبت لاگ در پروزه شما وجود نداشته باشد، احتمالا باید ساعت ها سردرگم به دنبال مشکل بگردید.
البته باید به این هم توجه کنید، این که شما برای یک برنامه log بنویسید لزوما به این معنی نیست که شما می توانید سریعا به مشکل رخ داده برسید، این موضوع به مهارت شما در نوشتن log از روال اجرای برنامه نیز بر می گردد .
در فصل دوم دوره رایگان آموزش asp.net core در سایت باگتو مبحث Logging in Asp.Net Core را آموزش داده ایم برای آشنایی بیشتر این قسمت ها را از دوره مشاهده کنید.
نکاتی که نباید در مورد Log فراموش کنید :
1. موضوع اولی که باید مورد بررسی قرار گیرد نحوه ی نوشتن log است.
Logباید به صورتی نوشته شود که هر کس دیگری غیر از شما هم آن را بخواند متوجه شود. به یاد داشته باشید همیشه شما نیستید که فایل log را میخوانید، خواننده ی فایل می تواند همکار شما یا حتی فردی در شرکت طرف قرار داد شما باشد.
2. از نوشتن اطلاعات مهم و امنیتی مربوط به کاربران برنامه یا خود برنامه در فایل log تا آنجا که ممکن است پرهیز کنید.
3. موضوع بعدی مدیریت اندازه ی فایل های ذخیره سازی log هاست. اگر اندازه این فایل ها بزرگ باشد و متن زیادی در آن نوشته شده باشد بررسی کردن آن ها دشوار است. بهتر است تنظیماتی انجام دهیم که اطلاعات مربوط به هر بازه ی زمانی مشخص در فایل جداگانه ذخیره شود. به طور مثال اطلاعات هر هفته یا هر روز در یک فایل جدا ذخیره شود.
4. زیاد ننویسیم کم هم ننویسیم. نوشتن بیش از اندازه ی اطلاعات در log کار را سخت می کند.
لاگ‌ها بخش مهمی از هر نرم‌افزار هستند. در این مقاله در مورد اینکه چگونه می‌توان لاگ را تأمل‌برانگیزتر کرد و درباره مواردی که باید در نظر داشته باشید و همچنین مواردی که هنگام LOG باید از آنها اجتناب کنید، صحبت می‌شود.
من مطمئن هستم که هر مهندس نرم‌افزاری در شرایطی غیرمنتظره قرار گرفته است که نتواند بفهمد در کد چه می‌گذرد؟
گاهی اوقات یک عبارت Insightful log می‌تواند برای پاسخ به این شرایط غیرمنتظره مفید باشد.
اجازه دهید به چند مورد بپردازیم که شخصاً آنها را پذیرفته‌ام و معتقدم که به‌اندازه کافی مناسب هستند تا دیگران بتوانند برای logging مؤثر و قابل درک از آنها پیروی کنند.
توجه: هنگام نوشتن این مقاله، کتابخانه log4j در نظر گرفته شده است.
برخی از سطوح مورداستفاده رایج لاگ: FATAL، ERROR ، WARN ، INFO ، DEBUG ، TRACE.
تفسیر ساده پیام‌های log levelsرایج:
• FATAL : نشان‌دهنده رخداد یک اشتباه جدی است که باید فوراً بررسی شود و راه حلی برای ازبین‌بردن آن پیدا کرد.
• ERROR : نشان‌دهنده یک اشتباه در روند برنامه است باید بررسی و برطرف شود.
• WARN : پیام‌هایی که برای پیگیری کردن رفتارهای خارج از انتظار برنامه است و به ما می‌گوید این روند ممکن است ادامه یابد، اما احتیاط بیشتری کنید.
• INFO : حاوی پیام‌های اطلاعاتی پیرامون برنامه و عملکرد آن (مثل روند تجاری مهم که تغییر حالت داده یا به پایان رسیده) است. باید توانایی درک پیام‌های INFO را داشته باشیم و به‌سرعت بفهمیم برنامه در حال انجام چه کاری است (این پیام‌ها برای کنترل روال اجرای برنامه است).
• DEBUG : نکات و اطلاعات راهنمای توسعه‌دهنده در پیداکردن باگ‌ها و رفع آنها.
• TRACE : اطلاعات بسیار دقیق و در سطح ریزتری، فقط برای توسعه در نظر گرفته شده است. به‌طورکلی، این برای موارد موقتی است .
مواردی که باید در نظر داشته باشید
• مدل‌های داده با متد toString () داشته باشید، این کار برای قراردادن داده‌های مهم در گزارش مفید خواهد بود. json همچنین برای ایجاد JSON برای شیء شما (ترجیحاً مدل‌های کوچک‌تر داده) وجود دارد.
• هر عبارت logging باید شامل داده‌ها و توضیحات باشد.
• استدلال‌های متد log و مقادیر برگشتی به‌عنوان DEBUG log که به‌عنوان یک دیباگر در چرخه توسعه کار می‌کند و همچنین برای اهداف تحقیق مفید است.
• هنگام فراخوانی سرویس‌های API خارجی، مطمئن شوید که همه چیز ثبت شده است. این کار به شناسایی مسائل جانبی کمک می‌کند، آیا ما در فراخوانی آن اشتباه کرده‌ایم یا پردازش API اشتباه کرده است؟
• مطمئن شوید که یک exception دو دفعه log نشده است. این کار منجر به درک نادرست خطا می‌شود.
• Logها باید برای خواندن آسان باشند.
• از log context برای ردیابی بهتر یک ریکوست استفاده کنید.
مواردی که باید از آنها اجتناب کنید
• از log.isDebugEnabled () برای لاگ‌های مستقیم خودداری کنید. از این موارد فقط در مواردی که برای logging نیاز به محاسبه است استفاده کنید.
• از ترکیب String با +استفاده نکنید، از جایگزین {} استفاده کنید.
• از obj.getAttribute () بدون اطمینان از اینکه obj خالی است یا خیر استفاده نکنید چون ممکن است منجر به NPE شود.
• از پرینت بیش از حد اشیاء خودداری کنید. مثال: فهرست <Object> نباید در یک گزارش واحد چاپ شود. بهتر است لیستی از objectID تهیه کرده و آن را وارد کنید.
• log PII داده‌ها را انجام ندهید.خیلی مهم است که هیچ اطلاعات شخصی وارد سیستم نشود. چون ممکن است باعث نقض GDPR شود.
• پسوردها و Secret Keys را لاگ نکنید. اطلاعات محرمانه، نباید لاگ شود.
لاگ‌ها باید به مهندسان نرم‌افزار کمک کند تا بدانند که کجا، چه چیزی و چرا مشکلی پیش‌آمده است.
اگر توسعه‌دهنده بتواند مشکلات را فقط از طریق لاگ‌ها پیدا کند، logging خوب است.
با شرکت در دوره مدیریت خطا در سی شارپ و Asp.Net Core می توانید تسلط کافی برای ثبت Log در Application های تحت .Net را بدیت بیاورید.
برای افزودن دیدگاه خود، نیاز است ابتدا وارد حساب کاربری‌تان شوید