ترجمه ی فارسی کلمه ی log ” ثبت وقایع” است. با استفاده از log اطلاعاتی را که هنگام بروز مشکل در برنامه بتوان برای رفع ایراد از آنها کمک گرفت، ثبت کنیم. تفاوت نوشتن log برای یک برنامه و ننوشتن آن را می توان با مثال صرف زمان 5 دقیقه برای رفع یک ایراد یا زمان 5 ساعتی برای آن توصیف کرد.البته باید به این هم توجه کنید، این که شما برای یک برنامه log بنویسید لزوما به این معنی نیست که شما می توانید سریعا به مشکل رخ داده برسید، این موضوع به مهارت شما در نوشتن log از روال اجرای برنامه نیز بر می گردد .
در فصل دوم دوره رایگان آموزش aspدر سایت باگتو مبحث Logging in Asp.Net Core را آموزش داده ایم برای آشنایی بیشتر این قسمت ها را از دوره مشاهده کنید
نکاتی که نباید در مورد Log فراموش شود :
- موضوع اولی که باید مورد بررسی قرار گیرد نحوه ی نوشتن log است. log باید به صورتی نوشته شود که هر کس دیگری غیر از شما هم آن را بخواند متوجه شود. به یاد داشته باشید همیشه شما نیستید که فایل log را میخوانید، خواننده ی فایل می تواند همکار شما یا حتی فردی در شرکت طرف قرار داد شما باشد.
- از نوشتن اطلاعات مهم و امنیتی مربوط به کاربران برنامه یا خود برنامه در فایل log تا آنجا که ممکن است پرهیز کنید.
- موضوع بعدی مدیریت اندازه ی فایل های ذخیره سازی log هاست. اگر اندازه این فایل ها بزرگ باشد و متن زیادی در آن نوشته شده باشد بررسی کردن آن ها دشوار است. بهتر است تنظیماتی انجام دهیم که اطلاعات مربوط به هر بازه ی زمانی مشخص در فایل جداگانه ذخیره شود. به طور مثال اطلاعات هر هفته یا هر روز در یک فایل جدا ذخیره شود.
- زیاد ننویسیم کم هم ننویسیم. نوشتن بیش از اندازه ی اطلاعات در 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 خوب است.
