محمد اژدری
محمد اژدری
خواندن ۴ دقیقه·۵ سال پیش

لاگ انداختن به زبان ساده :دی

اول از همه میخوام درمورد خود لاگ حرف بزنم. ما ها هر برنامه ای که مینویسیم اینجوریه که باید همیشه یک سری اطلاعات از اون رو بدیم بیرون که بفهمیم الان داره چه اتفاقی میافته ؟ اصلا برنامه کار میکنه ؟ ارور خورده یا نه ؟ اگه ارور خورده چه اروری خورده ؟و کجا این اتفاق افتاده ؟

اینجوری بگم که حجم کد که از یه حدی بزرگتر بشه، اگه اشکالی به‌ وجود بیاد عملا بدون دیدن لاگ ها نمیشه کاریش کرد و فهمید اشکال کار کجاست :(

پس در واقع لاگ انداختن یکی از شیوه های دیگه‌ی مانیتورینگه ک قبلا یه دونش رو گفتیم.

خب لاگ رو کی تولید میکنه ؟ معلومه ما (برنامه نویس) باید وقت هایی که احساس میکنه اینجا باید یک چیزی لاگ بشه باید اونجا این کار رو انجام بده.

دیگه نمیخوام زیاد وارد جزئیات بشم ولی لازم میدونم چند تا نکته رو همینجا بگم - شاید اصلا بعدا یک نوشته خصوصا برای چجوری لاگ خوب بندازیم رو بنویسم - :

سطح های لاگ ها:

لاگ ها سطح بندی دارن و اینجوریه که توی هر موقعیت باید لاگ مربوط به اون رو بندازیم. و میتونیم به سیستم لاگینگ‌مون بگیم که کدوم سطح از لاگ ها رو میخوایم ببینیم. این سطح ها عموما به ترتیب debug و info و error و critical هستن. (البته سطح های warning , exception هم هستن که من کم دیدم استفاده بشن.) این سطح هایی که گفتم از راست به چپ به ترتیب با اهمیت تر میشن. (چون عموما حجمشون خییلیه)

  • سطح debug: معمولا همه مراحله های یک برنامه رو روی سطح debug میندازیم و این سطح رو معمولا توی مرحله توسعه و دیباگ و اینجور مواقع به کار میبرن و توی مرحله production این رو غیرفعال میکنن.
  • سطح info : مرحله بعدی info هستش که اطلاعات مهم تری رو شامل میشه و برنامه نویس لازم میدونه که توی این سطح لاگ بشن و هی بتونه ببینه اون ها رو.
  • سطح error: توی این مرحله همونجوری که از اسمش پیداست، خطاهای برنامه لاگ میشن و باید مشخص بشه که چی بوده و از کجا و حتی از کدوم خط از کد بوده.
  • سطح critical : این سطح دیگه خطرناک ترین اتفاق های ممکن رو لاگ میکنه، مثلا میدونیم که اگه فلان اتفاق بیافته کل سیستم به فنا میره و از کار می‌افته، اونجا یه دونه از این ها میندازیم و روی این ها خیلی حساسیم که اگه دیدیمشون سریع باید یه کاری بکنیم.

خب تا الان احتمالا به اهمیت لاگ پی برده ایم و قانع شدیم که باید باشن.

کلا اگه بخوام یک تصور راحت بهتون بدم اینه که دیدید وقتی یک کدی رو داریم میزنیم و یه ایرادی داره اولین راهی که به ذهنمون میرسه میریم و چند تا پرینت توی قسمت های مختلف از برنامه میذاریم که ببینیم چه اتفاقی داره میافته و ایراد رو پیدا کنیم. لاگ کردن میشه حالت پیشرفته این کار که صرفا به قصد دیباگ کردن و فهمیدن خطا نیست و حتی بعدا میشه تحلیل های بیزینسی و آماری جالبی روی لاگ های برنامه کرد و چیز های جالبی از اون ها فهمید.

به جرئت میتونم بگم که همه زبون های برنامه نویسی logger دارن برای خودشون و با یک سرچ ساده که مثلا توی پایتون چجوری لاگ بندازیم ؟ میتونیم ببینیم چجوری دارن کار میکنن. (بازم اگر شد میام و درمورد لاگ انداختن توی زبون های معروف حرف میزنم.)

نکته بعدی اینه که لاگ ها معمولا یک سری فرمت هایی هم دارن که کاملا بستگی مستقیم به برنامه نویس اون سیستم داره. مثلا اینکه تاریخ و ساعت و کجا باشه و این ها،‌ این یک مثال ساده از لاگ لایبرری echo توی زبون Go هستش:

{&quotlevel&quot:&quotinfo&quot,&quotmsg&quot:&quot⇨ http server started on [::]:8000&quot,&quottime&quot:&quot2018-12-28T09:39:31Z&quot}

حالا یک مسئله ای پیش میاد و اونم اینه که الان برنامه من داره کار میکنه یک مشت لاگ رو داره میده بیرون و خیلی هم زیاد هستن و فی الواقع باید گفت یا ابلفضل : دی

خب این ها رو یه جوری باید مدیریت کرد و برای این روش های مختلفی وجود داره، ابتدایی ترین اون ها اینه که به کدمون بگیم روی همون کنسولی که روش اجرا شده یا یه مرحله بریم جلو تر رو یک سری فایل ذخیرشون کنیم و بعد دییتابیس و این داستانها. اما همه این ها (که بعضی هاشون لازمن و باید باشن بعضا) مشکلاتی دارن. مثلا یک مشت لاگ داریم که توی یک مشت فایله، سرچ توی اون ها و کلا مدیریتش هزینه (زمان) بره.

یک سری ابزار ها هستن که اینکار رو برای ما راحت تر میکنن و گری‌لاگ یکی از اون ها هستش. که برای طولانی نشدن مطلب توی نوشته بعدی بهش میپردازم.

logloggingprogrammingdevopsmonitoring
مهندس پایداری سایت در یکتانت
شاید از این پست‌ها خوشتان بیاید