آشنایی با مفهوم Structured Logging در توسعهٔ نرم‌افزار

پیشرفت روزافزون تکنولوژی، به‌تدریج زحمت انسان را کمتر و کمتر کرده است اما بعضی از کارکردهای انسان را تحت هیچ شرایطی نمی‌توان از تکنولوژی انتظار داشت! هوش‌مصنوعی در عالی‌ترین سطح پیشرفت هم نمی‌تواند با هوش بشر در یک سطح قرار بگیرد. یکی از مصداق‌های این تفاوت، توانایی آینده‌نگری بشر است. اگر دولوپر برای محصول خود آینده‌نگری نکند، حتی اگر تولیدکنندۀ پیشرفته‌ترین نرم‌افزار قابل تصور هم باشد، همان محصول می‌تواند مسبب نابودی خود و همچنین ایجاد انواع هزینه‌ها -اعم از مادی و غیرمادی- برای دولوپر خود شود. بدین ترتیب، برای جلوگیری از بروز انواع مشکلاتی که ممکن است در غیاب آینده‌نگری برای دولوپر پیش بیاید، او می‌بایست در پروسۀ تولید، آزمایش، و سپس عرضۀ محصول خود، به ریزترین و دقیق‌ترین موارد توجه کند و این مهم به‌دست نمی‌آید مگر با ثبت دقیق و جزیی‌نگرانۀ تمام اقداماتی که در تولید محصول صورت می‌گیرد که تحت‌عنوان Structured Logging شناخته می‌شود؛ چراکه در غیر این صورت، بخش قابل‌توجهی از فرایندهای پشت‌پردهٔ پروژه، به‌سادگی به‌دست فراموش سپرده خواهند شد.

چگونه لاگ‌های پروژه را به‌صورت منظم ثبت کنیم؟
می‌خواهیم نحوۀ ثبت لاگ‌های پروژۀ ساخت نرم‌افزار را از ابتدایی‌ترین مرحله بیاموزیم. شکی نیست که ثبت لاگ‌های پروژه به ساده‌سازی موضوعات مهمی مثل دیباگینگ، تحلیل و مانیتورینگ پروژه کمک می‌کند.

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

درواقع، فقط زمانی که نرم‌افزار به مرحلۀ نهایی رسیده و به شکل محصول درمی‌آید، دولوپر نسبت به گزارش عملکرد -مثلاً در رابطه با بروز Stack Trace- دقت می‌کند (Stack Trace که تحت عناوین دیگری همچون Stack Backtrace و یا Stack Traceback نیز شناخته می‌شود، خلاصه‌ای از روندی است که نرم‌افزاری پیموده تا به نقطهٔ فعلی رسیده است.)

گاهی اوقات دولوپر بلافاصله متوجه می‌شود که اشکال کار در کجاست اما در اغلب موارد دولوپر از ترتیب اتفاقاتی که منجر به ایجاد آن اشکال شده است، آگاهی ندارد و این عدم‌آگاهی باعث می‌شود که دولوپر بالاجبار کار خود را برای پیدا کردن مشکل، برمبنای حدس و گمان، کشف و جستجو به‌پیش ببرد که این مستلزم صرف زمان زیادی است.

کمپانی Thoughtworks در سایت Technology Radar در ماه می سال 2015، ثبت دقیق جزئیات (Structured Logging) را به دولوپرها پیشنهاد کرد. اما این اصطلاح به چه معنا است؟

آشنایی با مفهوم Structured Logging
بدون شک لاگینگ به‌صورت کامل، تنها برای تشخیص اشکالات پروژۀ نرم‌افزاری کاربرد ندارد. درصورتی‌که این کار به‌صورت دقیق انجام شود، می‌تواند به تحلیل تجاری محصول هم کمک کند. مثلاً نحوۀ کار کردن با سیستم را توضیح دهد؛ همچنین می‌تواند برای مانیتورینگ پروژه کمک‌کننده باشد. به‌عنوان مثالی دیگر، این امکان را فراهم می‌کند که دولوپر بفهمد چه نوع عملکردهایی در تولید نرم‌افزار مورد استفاده قرار گرفته است.

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

Structured Logging واقعاً چه‌ کاری برای دولوپر انجام می‌دهد؟
تصور غالب این است که پشتیبانی از محصول تولیدشده، نسبت به اضافه کردن آپشن‌ها و امکانات جدید برای محصول، از اهمیت بسیار کمتری برخوردار است؛ اما واقعیت این است که اگر پشتیبانی به‌درستی انجام شود، همیشه می‌توان امکانات جدید را به‌سادگی هرچه تمام‌تر به محصول اضافه نمود که همین مسئله منجر به بهبود کیفیت نرم‌افزار می‌شود.

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

در ادامه پرسش‌هایی را می‌بینید که با به‌کارگیری سیستم لاگینگ، پاسخگویی به آن‌ها بسیار ساده می‌شود (البته درصورتی که این سیستم از اولین لحظۀ شروع پروژه، به‌کار گرفته شود):

ایرادیابی
- چه اشکالی باعث بروز فلان Stack Trace شده است؟
- چه سلسله اتفاقاتی باعث شده است که دستوری که به نرم‌افزار داده شده است، به‌صورت ناگهانی اجرا نشود؟

تحلیل پروژه
- کاربران محصول تولیدشده چه کسانی هستند؟
- نظر کاربران بعد از استفادۀ طولانی‌مدت از محصول چیست؟
- کاربران، محصول تولیدشده را برای انجام چه کاری مورد استفاده قرار می‌دهند؟ 

مانیتورینگ
- چقدر زمان لازم است که نرم‌افزار، دستور صادر شده را پردازش کند؟
- چه میزان حافظۀ آزاد در نرم‌افزار موجود است؟

ملاحظات عملی
انفجار اطلاعاتی عظیمی در صنعت توسعهٔ نرم‌افزار درحال رخ دادن است؛ همچنین رشد فزاینده و فوق‌العاده‌ای در زیرساخت‌های صنایع ماشینی ایجاد شده است و در چنین شرایطی، کسب توانایی برای کشف ایرادات و ارتباط‌یابی میان اطلاعاتی که از سیستم‌های مختلف به‌دست می‌آید، ضرورتی بسیار مهم است.

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

فرمت مناسب برای لاگ‌ها
سؤال اینجا است که فرمت مناسب ثبت لاگ‌های سیستم چیست؟ به‌عبارت دیگر، فرمتی که برای انسان و ماشین قابل خواندن باشد. گزینه‌های مختلفی برای انجام این کار وجود دارد؛ به‌عنوان مثال، ثبت لاگ‌ها در قالب فایل‌های XML، ثبت در فایل‌های متنی و یا دیتابیس اما معروف‌ترین و شناخته‌شده‌ترین فرمت، JSON است.

گرچه یکسری ابزارها -همچون logstash- وجود دارند که فرمت‌های مختلف را به JSON تبدیل می‌کنند، اما بهتر آن است که در همان وهلهٔ اول، لاگ‌ها را در قالب جیسون ذخیره ساخت.

چه مواردی باید در لاگ ثبت شوند؟
لایبرری‌های استاندارد برای لاگ‌گیری مانند (Simple Logging Facade for Java (SLF4J، حاوی اطلاعات مفصل و مفیدی هستند که از آن جمله می‌توان به مواردی همچون timestamp ،pid ،thread ،level و loggername اشاره نمود (در صورت استفاده از این لایبرری، فقط لازم است این لیست را با اضافه کردن مواردی که به‌صورت خاص برای نرم‌افزار خود استفاده کرده‌ایم، کاستومایز کنیم.)

در صورتی‌که بخواهیم امکان دستیابی چندگانه و مانیتورینگ چندین سیستم و دیوایس را به‌صورت هم‌زمان به‌دست آوریم، نیاز به ایجاد یک توکن برای شناسایی عملکرد نرم‌افزار داریم که معمولاً تحت‌عنوان Request ID  یا Transaction ID نامیده می‌شود. این نوع توکن، این امکان را برای ابزار لاگ‌گیری فراهم می‌کند تا فقط روند اتفاقات و جزئیاتی را که به یک دستور خاص مرتبط هستند، استخراج کرده و نمایش دهد و این در حالی است که ممکن است این اطلاعات از چندین سیستم و دیوایس مختلف درمورد آن موضوع خاص استخراج شود (ممکن است برای انجام این کار، توکن Transaction ID به چندین سیستم مختلف انتقال داده شود که یکی از مهم‌ترین روش‌های انجام این انتقال عبارت است از هدرهای پروتکل HTTP.)

سطوح استاندارد لاگ‌گیری
اجزاء مختلف یک سیستم می‌بایست با سطح Logging که مورد استفاده قرار می‌گیرد، سازگار باشد. معمولاً برای یک سیستم در دست تولید، از Levelیی تحت‌عنوان INFO استفاده می‌شود و این در‌حالی است که در توسعۀ نرم‌افزار، سطح DEBUG استفاده می‌شود. با این توضیح مقدماتی، در ذیل مواردی را به‌صورت پیشنهادی ملاحظه می‌کنید که به شما برای تشخیص سطح مناسب برای استفاده در هر مرحله از پروژه کمک می‌کند:

ERROR: از این سطح برای ایرادات غیرقابل پیش‌بینی استفاده می‌شود؛ به‌عنوان مثال، قطع شدن کانکشن، ایرادات منطقی و یا کانفیگ اشتباه.

WARN: از این سطح برای ایرادات قابل پیش‌بینی استفاده می‌شود؛ به‌عنوان مثال، بروز مشکل در احراز هویت کاربر.

INFO: هر اطلاعاتی که در رابطه با تحلیل تجاری محصول است به‌علاوهٔ اطلاعات لازم برای دیباگینگ و مانیتورینگ در قالب سطح INFO ثبت می‌شوند؛ به‌عنوان مثال، انجام شدن درخواست کاربر، اسنپ‌شات‌هایی از میزان استفاده از ریسورس‌های سرور یا اطلاعات مربوط به زمانبندی.

DEBUG: از این سطح برای چیزهایی که باید در دیدرس دولوپر باشد استفاده می‌شود؛ به‌عنوان مثال، ورود به لایه‌های مختلف ساخت نرم‌افزار با استفاده از پارامترهای مختلف که فقط دولوپر به‌ آن‌ها دسترسی دارد.

TRACE: این سطح برای چیزهایی که ممکن است دولوپر به‌صورت موقت مورد استفاده قرار دهد به‌کار گرفته می‌شود؛ به‌عنوان مثال، دامپ دیتا.

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

- Graylog
- (Elasticsearch/Logstash/Kibana (ELK
- Loggly  
- Splunk

همۀ این ابزارها می‌توانند برای جستجوی لاگ‌ها در فرمت JSON مورد استفاده قرار بگیرند.

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