با لاگ‌گیری Verbose دچار دردسر خواهید شد!

لاگ گیری (Logging) به منزلهٔ بخشی مهم در فرایند توسعهٔ نرم‌افزار است. در واقع، این لاگ‌ها هستند که وقتی چیزی به درستی کار نمی‌کند، در فرایند مانیتورینگ نرم‌افزار چراغ راه دولوپر خواهند شد و تا حد ممکن وی را به سرچشمهٔ مشکل راهنمایی می‌کنند. در عین حال، در نظر داشته باشیم که همان‌قدر که نبود لاگ‌ها می‌توانند دولوپرها را فرایند دیباگینگ به دردسر بیاندازد، لاگ‌های غیرضروری و زیادی -اصطلاحاً Verbose- هم‌ می‌توانند آزاردهنده باشند!

نکته به طور کلی، منظور از Verbose Loggin نوعی از لاگ‌گیری است که در آن اطلاعاتی بیش از آنچه لازم است ذخیره خواهیم ساخت (Verbose در لغت به معنای «استفاده از واژگان بیش از حد» است). در واقع، Verbose Loggin زمان به کار می‌آید که نیاز به موشکافی دقیق یک سیستم نرم‌افزاری داشته باشیم و بخواهیم آن را دیباگ کنیم و در حالت عادی غیرفعال می‌گردد چرا که منجر به ایجاد لاگ فایل‌های بسیار حجیم خواهد شد. برای درک بهتر این مسأله، بایستی فرایند لاگ‌گیری نرم‌افزار را به علائم بیماری تشبیه کنیم. در حقیقت، ورم زیاد در ناحیهٔ شکم یک نوع علامت است و سرفه کردن هم‌ نوع دیگری از علائم بیماری. مسلماً کمتر کسی را می‌توان یافت که ورم ناحیهٔ شکم را جدی نگیرد و به آن بی‌توجهی کند چرا که از یک مشکل ساده در معده تا خدای ناکرده وجود یک غدهٔ سرطانی را می‌تواند شامل گردد اما این در حالی است که در بسیاری از مواقع، سرفه کردن صرفاً نشان از یک سرماخوردگی ساده دارد (البته همواره استثناء‌هایی وجود دارد).

البته در نظر داشته باشیم که فرایند لاگ‌گیری به همین سادگی‌ها نیست. به طور مثال، سرویس‌هایی که در آنها از چندین زبان‌ برنامه‌نویسی مختلف،‌ لایبرری و فریمورک استفاده شده است،‌ فرایند لاگ‌گیری بسیار پیچیده و دشوار خواهد بود و در چنین شرایطی حتماً می‌بایست این نکته را هم مد نظر داشته باشیم که گاهی‌اوقات ارور ایجاد شده کاملاً خارج از حیطهٔ اختیارات ما است (مثلاً زمانی که از API یک وب‌سایت دیگر استفاده می‌کنیم،‌ در صورت بروز مشکل در سرورهای آن وب‌سایت، مسلماً سرویس ما هم تحت‌الشعاع قرار خواهد گرفت).

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