نظارت مبتنی بر لاگ، سوابق دقیق رویدادها را برای عیبیابی عمیق ثبت میکند، در حالی که نظارت مبتنی بر معیارها، نقاط داده عددی را در طول زمان برای بینشهای عملکرد در زمان واقعی ردیابی میکند. هر دو رویکرد در پشتههای مشاهدهپذیری مدرن، اهداف متمایزی را دنبال میکنند و اکثر تیمها از استفاده همزمان آنها به جای انتخاب یکی بر دیگری سود میبرند.
رویدادهای گسسته را با جزئیات زمینهای ثبت میکند و امکان تجزیه و تحلیل قانونی و بررسی ریشهای علت را در سیستمهای توزیعشده فراهم میکند.
نقاط داده سری زمانی عددی را برای ردیابی سلامت سیستم، روند عملکرد و میزان استفاده از منابع در زمان واقعی جمعآوری میکند.
| ویژگی | نظارت مبتنی بر لاگ | نظارت مبتنی بر معیارها |
|---|---|---|
| نوع داده | سوابق رویداد با زمینه غنی | نقاط داده سری زمانی عددی |
| مورد استفاده اصلی | تحلیل ریشهای و اشکالزدایی | هشداردهی و تحلیل روند در لحظه |
| فضای ذخیرهسازی | حجم بیشتر برای هر ورودی، هزینههای ذخیرهسازی بالاتر | نقاط داده فشرده، هزینههای ذخیرهسازی کمتر |
| روش پرس و جو | جستجوی متن کامل و فیلتر کردن | تجمیع، توابع ریاضی، پرسوجوهای پنجره زمانی |
| زمان پاسخ | برای کوئریهای بزرگ کندتر است | تقریباً آنی برای پرسوجوهای داشبورد |
| بهترین برای پاسخگویی | چرا این رویداد خاص رخ داد؟ | وضعیت فعلی سیستم چیست؟ |
| ابزارهای رایج | استک ELK، اسپلانک، لوکی، فلوئنت | Prometheus، Grafana، Datadog، CloudWatch |
| قابلیت هشدار | محدود، اغلب به قوانین تجزیه لاگ نیاز دارد | هشدارهای مبتنی بر آستانه و ناهنجاری بومی |
نظارت مبتنی بر لاگ، هر رویداد گسسته را به همراه اطلاعات زمینهای اطراف آن، از جمله شناسههای کاربری، بارهای درخواست، ردگیریهای پشته خطا و متغیرهای محیطی، ثبت میکند. این امر، لاگها را در مواقعی که نیاز به بازسازی دقیق آنچه در طول یک حادثه خاص رخ داده است، دارید، بسیار ارزشمند میکند. در مقابل، نظارت مبتنی بر معیارها، رفتار سیستم را در مقادیر عددی خلاصه میکند و جزئیات رویداد منفرد را فدای یک قالب فشرده و قابل پرسوجو میکند که در افقهای زمانی طولانی به خوبی کار میکند.
پایگاههای داده معیار برای توان عملیاتی بالا در نوشتن و تجمیع سریع بهینه شدهاند، به همین دلیل است که پلتفرمهایی مانند Prometheus میتوانند هزاران هدف را هر چند ثانیه بدون هیچ زحمتی بررسی کنند. سیستمهای لاگ به سربار محاسباتی بیشتری نیاز دارند زیرا متنهای آزاد را فهرستبندی میکنند و از پرسوجوهای جستجوی پیچیده پشتیبانی میکنند. با افزایش حجم لاگها به ترابایت در روز، تیمها اغلب برای مدیریت هزینهها نیاز به سرمایهگذاری در ذخیرهسازی لایهای، استراتژیهای نمونهگیری یا سیاستهای نگهداری دارند.
معیارها وقتی صحبت از هشداردهی بلادرنگ میشود، میدرخشند، زیرا ارزیابی یک آستانه عددی در برابر یک سری زمانی از نظر محاسباتی بسیار ساده است. میتوانید هشدارهایی مانند «پردازنده بالای ۹۰٪ به مدت ۵ دقیقه» را با حداقل سربار تنظیم کنید. هشداردهی مبتنی بر گزارش امکانپذیر است، اما معمولاً برای تشخیص الگوها به قوانین تجزیه یا موتورهای جستجوی گزارش نیاز دارد که باعث افزایش تأخیر و پیچیدگی میشود. برای اعلانهای فوری در مورد سلامت سیستم، معیارها معمولاً مسیر سریعتری هستند.
وقتی چیزی خراب میشود، مهندسان اغلب اولین جایی که به آن نگاه میکنند، لاگها هستند زیرا روایت آنچه رخ داده را حفظ میکنند. یک ورودی لاگ میتواند پیام خطای دقیق، کاربر آسیبدیده و مسیر کدی که باعث خرابی شده است را آشکار کند. معیارها میتوانند به شما بگویند که میزان خطا در ساعت 2:34 بعد از ظهر به شدت افزایش یافته است، اما به ندرت دلیل آن را توضیح میدهند. به همین دلیل است که تیمهای مهندسی بالغ، لاگها را به عنوان ابزار تحقیق و معیارها را به عنوان سیستم هشدار اولیه خود در نظر میگیرند.
ذخیره لاگها عموماً گرانتر از ذخیره معیارها است، زیرا هر ورودی دادههای بیشتری را در خود جای میدهد و دورههای نگهداری اغلب به دلایل انطباق یا حسابرسی طولانیتر هستند. یک برنامه متوسط ممکن است روزانه میلیونها خط لاگ تولید کند، در حالی که تنها چند صد سری معیار منحصر به فرد تولید میکند. بسیاری از سازمانها نمونهگیری لاگ، فیلتر کردن در منبع یا ذخیرهسازی لایهای را برای کنترل هزینهها پیادهسازی میکنند، در حالی که نگهداری معیارها معمولاً میتواند با هزینهای کم تا ماهها یا سالها ادامه یابد.
سه رکن مشاهدهپذیری، لاگها، معیارها و ردیابیها هستند و اکثر سیستمهای در سطح تولید به هر سه متکی هستند. معیارها، نمای کلی سلامت را در سطح بالا ارائه میدهند، لاگها جزئیات تشخیصی عمیق را ارائه میدهند و ردیابیهای توزیعشده با نشان دادن جریان درخواستها در سراسر سرویسها، این دو را به هم متصل میکنند. انتخاب بین نظارت مبتنی بر لاگ و مبتنی بر معیارها به ندرت یک تصمیم یا یکی از این دو است. در عوض، تیمها تصمیم میگیرند که چگونه سرمایهگذاری در هر یک را بر اساس نیازهای عملیاتی و بودجه خود متعادل کنند.
برای اجرای یک سیستم قابل اعتماد، فقط به یک نوع نظارت نیاز دارید.
اکثر سیستمهای تولیدی از هر دو رویکرد سود میبرند. معیارها مشکلات را از طریق هشدارها در مراحل اولیه شناسایی میکنند، در حالی که گزارشها به مهندسان کمک میکنند تا پس از شناسایی یک مشکل، علت اصلی آن را درک کنند. تکیه بر تنها یکی از این رویکردها، نقاط کوری را ایجاد میکند که میتواند باعث طولانی شدن قطعیها شود.
چوبها همیشه برای نگهداری طولانی مدت خیلی گران هستند.
اگرچه ذخیرهسازی لاگ خام میتواند پرهزینه باشد، اما استراتژیهای ذخیرهسازی لایهای، فشردهسازی و نمونهبرداری هوشمند، نگهداری طولانیمدت را امکانپذیر میکند. بسیاری از چارچوبهای انطباق در واقع نیاز به نگهداری لاگهای خاص برای ماهها یا سالها دارند، بنابراین مدیریت هزینه بیشتر مربوط به استراتژی است تا اجتناب از آن.
معیارها میتوانند جایگزین گزارشها برای اشکالزدایی شوند.
معیارها به شما میگویند که چیزی تغییر کرده است، اما به ندرت دلیل آن را توضیح میدهند. هنگام بررسی شکایت یک کاربر خاص یا یک خطای نادر، گزارشها معمولاً تنها راه برای یافتن علت واقعی هستند. معیارها و گزارشها نقشهای مکملی در پاسخ به حادثه ایفا میکنند.
دادههای لاگ بیشتر همیشه به معنای نظارت بهتر است.
ثبت بیش از حد وقایع باعث ایجاد نویز، افزایش هزینهها و در واقع کند شدن روند عیبیابی میشود. نظارت مؤثر مبتنی بر وقایع، به جای ارائه تمام جزئیات ممکن در قالب متن بدون ساختار، بر ثبت رویدادهای معنادار با فیلدهای ساختاریافته تمرکز دارد.
نظارت مبتنی بر معیارها، هر ناهنجاری را به طور خودکار ثبت میکند.
معیارها فقط آنچه را که شما به صراحت اندازهگیری میکنید، تشخیص میدهند. اگر یک حالت خرابی جدید ظاهر شود که هیچکس به فکر ردیابی آن نبوده است، معیارها آن را به طور کامل از دست خواهند داد. در مقابل، گزارشها، رویدادهای غیرمنتظره را تا زمانی که برنامه در حال نوشتن آنهاست، ثبت میکنند.
زمانی که نیاز اصلی شما اشکالزدایی عمیق، ردیابی ممیزی یا درک زمینه پشت رویدادهای خاص است، مانیتورینگ مبتنی بر لاگ را انتخاب کنید. زمانی که به داشبوردهای بلادرنگ، هشدار سریع و تحلیل روند بلندمدت در مقیاس بزرگ نیاز دارید، مانیتورینگ مبتنی بر معیارها را انتخاب کنید. در عمل، قویترین استراتژیهای مشاهدهپذیری هر دو را با هم ترکیب میکنند، از معیارها برای تشخیص زودهنگام و لاگها برای بررسی کامل استفاده میکنند.
این مقایسه به بررسی خدمات وب آمازون و گوگل کلود میپردازد و با تحلیل پیشنهادات خدماتی، مدلهای قیمتگذاری، زیرساخت جهانی، عملکرد، تجربه توسعهدهندگان و موارد استفاده ایدهآل، به سازمانها کمک میکند تا پلتفرم ابری را انتخاب کنند که بهترین تطابق را با نیازهای فنی و تجاری آنها داشته باشد.
محاسبات لبهای یادگیری ماشینی (ML) استنتاج را مستقیماً روی دستگاههای محلی اجرا میکند و تأخیر و استفاده از پهنای باند را کاهش میدهد، در حالی که آموزش یادگیری ماشینی مبتنی بر ابر، از سرورهای قدرتمند از راه دور برای ساخت و اصلاح مدلهای عظیم استفاده میکند. هر رویکرد متناسب با مراحل مختلف چرخه عمر یادگیری ماشینی و تقاضاهای عملیاتی مختلف است.
استراتژیهای ذخیرهسازی در سیستمهای یادگیری ماشین، خروجیهای مدل از پیش محاسبهشده یا دادههای میانی را برای تسریع پرسوجوهای مکرر ذخیره میکنند، در حالی که محاسبات بر اساس تقاضا، هر بار نتایج تازهای تولید میکنند و سرعت را فدای سادگی و سربار ذخیرهسازی کمتر میکنند.
اشکالزدایی سیستمهای توزیعشده، به بررسی خرابیها در چندین ماشین و سرویس شبکهای میپردازد، در حالی که اشکالزدایی سیستم محلی بر مشکلات درون یک ماشین یا برنامه واحد تمرکز دارد. هر رویکرد، ابزارها، مدلهای ذهنی و استراتژیهای متفاوتی را برای جداسازی و حل مؤثر مشکلات میطلبد.
برنامهریزی زیرساخت بلاکچین بر طراحی شبکههای غیرمتمرکز و توزیعشده با دفترکلهای تغییرناپذیر و سازوکارهای اجماع تمرکز دارد، در حالی که برنامهریزی زیرساخت ابری بر ساخت منابع محاسباتی مقیاسپذیر و بر اساس تقاضا از طریق ارائهدهندگان متمرکز مانند AWS، Azure و Google Cloud متمرکز است.
