امروزه ادمین سرویس‌ها با استفاده از لاگ‌هایی که سرویس‌ها در اختیار آن‌ها قرار می‌دهند از تمام کارهای سرویس مطلع هستند. این لاگ‌ها ارزش بسیاری دارند و برای خطایابی و بهبود سرویس‌ها مکررا مورد استفاده قرار می‌گیرند. برای بهبود و خطایابی با استفاده از لاگ‌ها، باید آن‌ها را جمع‌آوری، ذخیره و تحلیل کرد. در سری مقالات آنالیز لاگ سعی داریم که روند جمع‌آوری و تحلیل لاگ را به صورت جامع بررسی کنیم. در گام اول در این مقاله به طور خلاصه به تاریخچه اتفاقات و دلایل پیدایش و نیاز به وجود لاگ و تولید آن خواهیم پرداخت.
سری آنالیز لاگ شامل گام‌های زیر می‌باشد:
- تاریخچه‌ی کوتاهی از تغییرات در مورد لاگ‌ها
- تکنولوژی‌های ذخیره‌سازی و جمع‌آوری لاگ‌ها
- مطالعه‌ی موردی در مورد سرویس‌های معروف لاگ
- بررسی اهداف و آماده‌سازی برای آنالیز لاگ‌ها
- استخراج، تبدیل و بارگذاری (Extract-Transform-Load) لاگ‌ها
- آنالیز آماری لاگ‌ها
قبل از هرچیز خاطر نشان می‌کنیم که تلاش بسیار ما برای پیدا کردن واژه‌ی فارسی معادل لاگ که گویای معنی حقیقی و کاربردی آن باشد بی نتیجه ماند. از همین رو تا ایجاد یک معادل فارسی گویا برای این واژه از خود کلمه «لاگ» استفاده خواهیم کرد.
پیدایش لاگ
در سال‌های خیلی دور، با تعداد اندکی کاربر و محدودیت دسترسی عمومی به سیستم‌ها، تشخیص اینکه داده‌ی ورودی به‌وسیله‌ی چه کسی و از کجا وارد می‌شود، مشکل نبود و به تبع آن شناسایی کاربر منحصر به فرد نیز به راحتی قابل انجام بوده است. با معرفی سیستم‌هایی عمومی مانند سیستم‌های کتابخانه‌ها، دانشگاه‌ها و دیگر مراکزی که PCها برای استفاده عموم قرار داده شده بود، خرده خرده تشخیص کاربران مشکل گردید. در آن زمان تشخیص اینکه ورودی به وسیلهی چه کسی و از کجا وارد می‌شود، شبیه این بود که شما تلاش کنید که در یک جمع که همه در حال صحبت هستند، تشخیص دهید که چه کسی با چه کسی و در مورد چه چیزی صحبت می‌کند و صحبتشان چقدر طول کشیده است.
استفاده اولیه از آنالیز لاگ
در این سال‌ها که به اواخر دهه‌ی 1960 بر می‌گردد، محیط UNIX روزهای ابتدایی خود را سپری می‌کرد و ابزاری برای جمع‌آوری لاگ‌ها از چندین منبع مختلف نداشت. حتی این سرویس که بتوان لاگ را از فرمتی به فرمتی دیگر تبدیل کرد نیز در اختیار نبود. هیچ ابزاری برای نظارت بر داده‌های ورودی به صورت آنلاین و ارسال هشدار به ادمین‌ها نیز ارائه نشده بود و از همه واضح‌تر اینکه GUI کاربرپسند هم وجود خارجی نداشت. با این همه جای تعجب نیست اگر به محیط CLI سیستم لینوکس امروزی یا سایر سیستم‌های مشابه مبتنی بر یونیکس نگاهی بیندازید، متوجه خواهید شد که تعدادی از ابتدایی‌ترین ابزارهای نصب‌شده در آن به شما در جستجو یا تبدیل متن کمک می‌کنند. در واقع این ابزارها بر اساس همان سرویس‌هایی به وجود آمده‌اند که در روزهای اولیه وجود داشته‌اند و در حال حاضر رشد زیادی کرده‌اند. مثال‌هایی از آن‌ها عبارتند از: grep ، head، tail و sed.
کمی بعدتر
چند دهه بعد در دهه‌ی 1990 و در زمانی که مدل توسعه نرم‌افزار Waterfall رایج شده بود، آنالیز لاگ بسیار پیچیده‌تر شد. سیستم عامل‌ها برای کارهایی مثل بوت‌شدن و اتفاقات درون سیستم، لاگ‌های جداگانه‌ای نگهداری می‌کردند، و هر برنامه‌ای که بر روی آن‌ها اجرا می‌شد به طور مستقل لاگ‌های خود را نگه می‌داشتند. کم‌کم پیاده‌سازی نرم افزارها به صورت توزیع‌شده انجام می‌شد و نیاز به جمع‌آوری لاگ‌ها بیشتر خود را نشان می‌داد.
این مجموعه از خواسته‌ها باعث شد که سرویس‌های جدید مانند syslog-ng و rsyslog راه‌اندازی شوند که به ترتیب در سال 1998 و 2004 شروع به کار کردند. این دو سرویس قابلیت‌های بسیار مهمی از جمله پشتیبانی از جمع‌آوری لاگ‌ها در شبکه را در اختیار قرار می‌دادند. این ابزارها به ادمین‌ها دید بهتری از سیستم می‌دادند اما نیاز به تجزیه و تحلیل دستی هنوز احساس می‌شد. شاید در آن زمان چنین موضوعی مشکل جدی به حساب نمی‌آمد، چرا که در آن زمان به روزرسانی نرم‌افزارها به کندی صورت می‌گرفت و ممکن بود هر سرویس چند ماه طول بکشد تا به‌روزرسانی شود. به همین دلیل به راحتی سرویس‌دهندگان می‌توانستند لاگ را به صورت دستی جمع‌آوری کنند و بر اساس آن سرویس خود را آنالیز نمایند.
آنالیز لاگ درحال حاضر
اما پس از چند سال شرایط تغییر کرد. مدل نرم افزاریWaterfall جای خود را به DevOps داد و همزمان تکنیک‌های جدید تجزیه و تحلیل برای آن به وجود آمد. در DevOps، عملیات خودکار، همه چیز بود و در عمل تحویل گزارش و بازخورد مستمر، تحلیل‌های دستی را غیرکاربردی می‌کرد. محدودیت‌های تحلیل‌های دستی برای این روش عبارت بودند از:
- در محیط سازمانی با مقیاس بزرگ، لاگ‌ها عموما با سرعت بیش از ده هزار لاگ بر ثانیه تولید می‌شوند. تجزیه و تحلیل دستی زمانی که نرخ تولید لاگ بیشتر و بیشتر می شود دیگر کار آسانی نیست.
- بررسی دستی برای لاگ‌های ساده، آسان است اما زمانی که لاگ پیچیده‌تر می‌شود و یا زمانی که نیاز است تعداد زیادی لاگ برای پی‌بردن به دلیل اتفاقی به صورت همزمان بررسی شوند و یا روند این لاگ‌ها بررسی شود، دیگر با روش‌های دستی نمی‌توان این کار را انجام داد.
- ابزارهای ساده و بررسی دستی احتمالاً هرگز تصویر بزرگی از آنچه در محیط اتفاق می‌افتند را ارائه نمی‌دهند، اما ابزارهای پیشرفته‌تر می‌توانند چنین تصویری را از داده‌های لاگ تهیه کنند.
- خیلی اوقات زمانی که لاگ‌ها ابهام دارند و کمی گیج‌کننده هستند، می‌بایست چندین منبع را در کنار هم تجزیه و تحلیل کرد. این کار به صورت دستی می‌تواند انجام شود ولی زمان زیادی برای آن مورد نیاز است و بهتر است از ابزارهای خودکار استفاده شود.
- مهم‌تر از همه اینکه تحلیل دستی یک کار بسیار خسته‌کننده و فرساینده است. خستگی و بی‌حوصلگی، کارآیی یک تحلیل‌گر را سریع‌تر از آنچه فکرش را بکنید کاهش می‌دهد.
جمع‌آوری لاگ
به طور خلاصه می‌توان گفت تجزیه و تحلیل منابع مختلف به صورت جداگانه ناکارآمد خواهد بود و به همین دلیل ابزار جمع‌آوری و ادغام لاگ‌ها یکی از مهم‌ترین ضروریات است. این ابزارها، لاگ‌ها را از مکان‌‌های مختلف جمع‌آوری می‌کنند (حتی اگر نوع لاگ‌ها با هم فرق کنند) و به ادمین سیستم اجازه می‌دهند که همه‌ی لاگ‌ها را یکجا ببیند. در واقع امروزه به جای اینکه برای هر سرویس لاگ جدا وجود داشته باشد، یک سرویس لاگ، تمامی لاگ‌ها را یکجا جمع‌آوری کرده و ادمین سیستم به راحتی می‌تواند از تجمیع آن‌ها، سرویس‌های خود را آنالیز کرده و بهبود بخشد.
این مقاله ادامه دارد…
