به احتمال خیلی زیاد داخل برنامه هایی که تا به حال نوشته اید از لاگ کردن استفاده کرده اید. عیب یابی برنامه، برای مقاصد تجاری و بهبود کسب و کار و نظارت بر عملکرد برنامه از جمله کاربردهایی هستند که می توان برای لاگ نام برد. لاگ کردن در واقع تاریخچه ای است از فعالیت هایی که برنامه شما انجام داده است.
اما تا به حال به اصول لاگ کردن فکر کرده اید و اینکه چطور می توانید حرفه ای تر و اصولی تر از لاگ استفاده کنید.در این مطلب با برخی از اصول و قواعد استفاده از لاگ به صورت حرفه ای آشنا می شویم.
یکی از سوالاتی که همیشه ذهن مرا درباره استفاده از لاگ مشغول کرده بود این سوال بود که چه چیزهایی را باید لاگ کنیم؟
چه چیزهایی را باید لاگ کنید؟
رویدادهایی را لاگ کنید به شما کمک می کنند رفتار برنامه تان را مشاهده کنید. بنابراین همیشه رویدادهای زیر را لاگ کنید:
- خطاهای برنامه
- خطاهای اعتبار سنجی در ورودی و خروجی ها
- موفقیت و شکست در احراز هویت (authentication)
- شکست در دسترسی ها به بخش های خاص (authorization)
- خطا در مدیریت نشست ها
- موفقیت و شکست در ارتقا دسترسی ها
- در ورود و خروج داده ها
- ورود اولیه به برنامه
- رویدادهایی مربوط به رعایت قوانین
چه چیزهایی را نباید لاگ کنید؟
یک اصل کلی در این مورد وجود دارد هر چیزی که مربوط به امنیت و رعایت قوانین می شود را از فرآیند لاگ خارج کنید. اطلاعات شخصی افراد، کلیدهای رمزنگاری، اطلاعات مربوط به دسترسی به پایگاه داده، اطلاعات کارت های اعتباری و … از جمله مواردی هستند که نباید در لاگ های شما وجود داشته باشند.
بعد از باید ها و نباید ها نوبت به جزییات می رسد اینکه چطور پیام های لاگ را بهبود دهیم تا بتوانیم از لاگ کردن نهایت استفاده را ببریم.
لاگ باید چه جزییاتی داشته باشد؟
سعی کنید پیام لاگ شرایط وقوع لاگ را در بر داشته باشد. بناباین این اطلاعات را داخل پیام لاگ تان قرار دهید:
- چه فعالیتی در حال انجام بوده است.
- چه کسی در حال انجام فعالیت بوده است.
- چرا شکست رخ داده است.
- اطلاعات اصلاحی برای لاگ در سطح warn و error
- کد درخواست (HTTP Request ID) در برنامه ها تحت وب
این پیام را در نظر بگیرید که حاوی اطلاعات کافی نیست:
2019-06-20T17:21:00.002899+00:00 app[web.1]: INFO: Address removed.
این پیام تنها مکان و زمان رویداد را نشان می دهد و یک توضیح کلی درباره اینکه چه اتفاقی رخ داده است. اما می توان این پیام را به این صورت تکمیل تر کرد:
2019-06-20T17:21:00.002899+00:00 app[web.1]: INFO: Address removed by customer. {“addressid”:18344857, “customerid”:50333}
این پیام نشان دهنده این موضوع است که این رویداد در چه زمانی، در چه مکانی، توسط چه کسی انجام شده است و چه چیزی حذف شده است.
از سطح درست استفاده کنید.
همیشه سعی کنید از سطح درست لاگ استفاده کنید. برای این منظور با سطوح مختلف لاگ آشنا می شویم.
INFO: پیام های اطلاعاتی که خطا یا مشکلی را نشان نمی دهند. اما می توانند حاوی اطلاعات باشند که در طولانی مدت ارزشمند باشند. این نوع پیام ها روند کلی برنامه را نشان می دهند.
مثال:
- پایان موفقیت آمیز یک کار برنامه ریزی شده
- ایجاد، ویرایش یا حذف یک رکورد در پایگاه داده
- گوش دادن برنامه به یک پورت خاص
WARN: این پیام می تواند نشان دهنده یک مشکل در برنامه باشند که البته کاربر متوجه آن نمی شود. این نوع پیام ها مشکلاتی را نشان می دهند که باعث از کار افتادن برنامه نمی شوند.
مثال:
- استفاده بیش از اندازه از هارد دیسک
- استفاده بیش از اندازه از رم
- زمان طولانی برای انجام یک وظیفه مهم در برنامه
ERROR: نشان دهنده یک مشکل در برنامه است که کاربر نیز متوجه آن می شود و ممکن است بر روی تجربه کاربر نیز تاثیر بگذارد. این مشکل یا خطا باعث از کار افتادن کامل برنامه نمی شود اما می تواند عملکرد برنامه را کاهش دهد یا باعث شود برخی از ویژگی های برنامه قابل استفاده نباشند.
مثال:
- خطا در برقراری ارتباط با یک سرویس بعد از اتمام تلاش های مجدد
- خطا در ایجاد یک فایل در هارد دیسک
- خطا در دیکد کردن فایل json
FATAL: نشان دهنده یک مشکل جدی در برنامه است که استفاده کاربر از برنامه را به شدت تحت تاثیر قرار می دهد و برنامه قادر به انجام عملکردهای مورد انتظار نیست. این مشکلات بدون دخالت برنامه نویس قابل رفع نیستند.
مثال:
- در دسترس نبودن فایل های پیکربندی
- عدم دسترسی به پایگاه داده
- پر شدن ظرفیت هارد دیسک سرور
DEBUG: هدف این پیام ها برنامه نویس است و برای رفع باگ های برنامه کاربرد دارد.
TRACE: این نوع پیام ها برای رصد روند اجرای کد برنامه مورد استفاده قرار می گیرند.
مثال:
- ردگیری یک درخواست
- مراحل انجام یک الگوریتم برای حل یک مسئله
- ورود و خروج از یک متد با تعیین زمان پردازش متد
منابع:
1. https://devcenter.heroku.com/articles/writing-best-practices-for-application-logs
2. https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-7.0
3. https://betterstack.com/community/guides/logging/log-levels-explained/
