انتخاب استراتژی مناسب برای مشاهدهپذیری نیازمند درک نحوه جمعآوری و پردازش دادهها است. در حالی که نظارت سری زمانی، معیارهای عددی سیستم را در فواصل منظم ردیابی میکند تا روندهای سلامت بلندمدت را کشف کند، نظارت رویدادمحور، تغییرات حالت گسسته را بلافاصله ثبت میکند تا پاسخهای برنامهریزیشده فوری را ایجاد کند و طرحهای معماری آنها را اساساً متفاوت سازد.
برجستهها
سریهای زمانی به نظرسنجی بازههای زمانی قابل پیشبینی متکی هستند، در حالی که نظارت بر رویداد صرفاً بر اساس تقاضا عمل میکند.
تلهمتری رویداد، زمینهی بار عمیق را حفظ میکند که معیارهای عددی سنتی آن را نادیده میگیرند.
الزامات ذخیرهسازی برای سریهای زمانی ثابت میماند، در حالی که ذخیرهسازی رویداد، افزایش ناگهانی فعالیتهای سیستم را ردیابی میکند.
تنظیمات مبتنی بر رویداد، به جای تجزیه و تحلیل گذشتهنگر، امکان خودترمیمی خودکار و فوری را فراهم میکنند.
نظارت بر سریهای زمانی چیست؟
یک رویکرد متمرکز بر معیارها که نقاط داده عددی را در فواصل زمانی ثابت و منظم جمعآوری میکند تا روندهای سیستم را تجزیه و تحلیل کند.
به شدت به فواصل منظم نظرسنجی، مانند جمعآوری دادهها هر پانزده ثانیه، متکی است.
دادهها را به صورت مقادیر عددی ساختاریافته و مقید به مهرهای زمانی و برچسبهای ابعادی خاص ذخیره میکند.
برای پرسوجوهای تجمیعی با کارایی بالا مانند محاسبه میانگین استفاده از CPU در طول یک ماه بهینه شده است.
معمولاً از معماری مبتنی بر pull استفاده میکند که در آن یک سرور مرکزی دادهها را از نقاط انتهایی هدف درخواست میکند.
رشد قابل پیشبینی فضای ذخیرهسازی را حفظ میکند زیرا نرخ دریافت دادهها صرف نظر از بار سیستم ثابت میماند.
مانیتورینگ رویداد محور چیست؟
یک سیستم واکنشی که بستههای داده غنی از متن را به محض وقوع یک تغییر حالت خاص، دریافت و پردازش میکند.
به صورت غیرهمزمان عمل میکند و فقط زمانی اقدامات را اجرا میکند که یک وضعیت تعریفشده یا حادثه سیستمی باعث ایجاد هشدار شود.
فرادادههای زمینهای عمیق درون هر بسته، شامل جزئیات کامل بار داده و شناسههای کاربر را ضبط میکند.
از یک معماری مبتنی بر push استفاده میکند که در آن برنامههای کاربردی منفرد، رویدادها را بلافاصله به یک گذرگاه رویداد (event bus) ارسال میکنند.
نیازهای ذخیرهسازی به صورت پویا با فعالیت سیستم مقیاسپذیر میشوند و در هنگام افزایش ناگهانی ترافیک، به شدت افزایش مییابند.
مستقیماً با ابزارهای اتوماسیون ادغام میشود تا زیرساختها را فوراً و بدون نیاز به دخالت انسان، خود-ترمیم کند.
جدول مقایسه
ویژگی
نظارت بر سریهای زمانی
مانیتورینگ رویداد محور
محرک جمعآوری دادهها
فواصل زمانی منظم و از پیش تعریف شده
وقوع فوری تغییر وضعیت
قالب داده اولیه
جفتهای کلید-مقدار عددی با مهرهای زمانی
JSON غنی یا فایلهای متنی ساختاریافته
الگوی معماری
خراشیدن عمدتاً مبتنی بر کشش
پخش مبتنی بر فشار از طریق کارگزاران پیام
رشد ذخیرهسازی
بسیار قابل پیشبینی و خطی
متغیر و مستقیماً به فعالیت سیستم وابسته است
مورد استفاده ایدهآل
برنامهریزی ظرفیت و تحلیل روند بلندمدت
پاسخ فوری به حوادث و خوددرمانی خودکار
تمرکز پرس و جو
تجمیعهای ریاضی در طول پنجرههای زمانی
ردیابی مسیرهای رویداد فردی و جهشهای ساختاری
سربار سیستم
ردپای کم و ثابت از منابع
مصرف متغیر منابع بر اساس حجم رویداد
مقایسه دقیق
مکانیکهای جذب داده
نظارت بر سریهای زمانی مانند یک ضربان قلب ثابت عمل میکند و در فواصل زمانی ثابت از سیستمها پرسوجو میکند تا تصاویر لحظهای از عملکرد را جمعآوری کند. این رویکرد تضمین میکند که شما یک جریان مداوم از دادههای عددی دریافت میکنید و به موتورها اجازه میدهد تا به راحتی مسیرهای تاریخی را ترسیم کنند. از طرف دیگر، نظارت مبتنی بر رویداد تا زمانی که چیزی خاص محیط را تغییر ندهد، بیصدا میماند و فوراً یک بسته داده جامع را به جلو ارسال میکند. این بدان معناست که مدل مبتنی بر رویداد در دورههای آرام غیرفعال میماند، اما در میلیثانیه پس از وقوع خطا، با جزئیات بسیار زیاد وارد عمل میشود.
جزئیات و زمینه
هنگام مواجهه با وظایف تشخیصی عمیق، تفاوتها در عمق دادهها آشکار میشوند. ساختارهای سری زمانی متن و زمینه را حذف میکنند تا صرفاً بر اعداد تمرکز کنند، که باعث میشود همه چیز ساده بماند اما داستان پشت خرابی را از قلم میاندازد. گزارشهای رویداد محور، کل پسزمینه متنی را دست نخورده نگه میدارند و دقیقاً به شما میگویند کدام کاربر یا تابع باعث خرابی مسیر اجرا شده است. در حالی که یک نمودار سری زمانی، افزایش ناگهانی اتصالات پایگاه داده شما را نشان میدهد، یک جریان رویداد، پرسوجوی دقیقی را که باعث شروع مشکل شده است، به شما نشان میدهد.
مقیاسپذیری و دینامیک ذخیرهسازی
مدیریت ردپای مالی و ذخیرهسازی این پلتفرمها نیازمند دو طرز فکر کاملاً متفاوت است. تنظیمات سری زمانی، پیشبینیپذیری راحتی را ارائه میدهند، زیرا افزایش مقیاس معمولاً فقط به معنای تنظیم سیاستهای نگهداری یا افزایش فواصل نظرسنجی شماست. سیستمهای مبتنی بر رویداد بسیار ناپایدارتر هستند و به معماری ذخیرهسازی نیاز دارند که بتواند سیل ناگهانی و عظیم دادهها را هنگام بروز خطاها از طریق میکروسرویسها مدیریت کند. اگر برنامه شما ویروسی شود یا مورد حمله DDoS قرار گیرد، الزامات ذخیرهسازی رویداد همزمان با ترافیک ورودی به شدت افزایش مییابد.
سرعت عمل و هشدار
سرعت واکنش تیم عملیاتی شما کاملاً به نحوه ارائه تلهمتری شما بستگی دارد. هشدارهای سری زمانی به طور طبیعی از کمی تأخیر رنج میبرند، زیرا سیستم باید منتظر چرخه بعدی scrape بماند و چندین نقطه داده را برای تأیید یک روند ارزیابی کند. معماریهای رویداد محور با حذف واسطه، مسیریابی مستقیم خرابیهای بحرانی به پلتفرمهای اعلان یا اسکریپتهای مقیاسبندی خودکار در لحظه وقوع، در اینجا برتری دارند. این قابلیت اعلان فوری، رویکرد رویداد محور را برای زیرساختهای حیاتی ماموریت که نیاز به اصلاح فوری دارند، ضروری میکند.
مزایا و معایب
نظارت بر سریهای زمانی
مزایا
+هزینههای ذخیرهسازی بسیار قابل پیشبینی
+تحلیل روند بلندمدت عالی
+سربار منابع کم
+تجمیع ریاضی سادهشده
مصرف شده
−فاقد متن دقیق و جزئی است
−تأخیرهای ذاتی در رأیگیری ایجاد میکند
−جهشهای کوتاه و متناوب را از دست میدهد
−مبارزه با زیرساختهای زودگذر
مانیتورینگ رویداد محور
مزایا
+هشداردهی لحظهای و بلادرنگ
+حفظ غنی فرادادههای موقعیتی
+مناسب برای سیستمهای جدا از هم
+گردشهای کاری خودکار را مستقیماً فعال میکند
مصرف شده
−مصرف غیرقابل پیشبینی فضای ذخیرهسازی
−پیچیدگی بالای پیکربندی معماری
−تجزیه و تحلیل روندهای کلان دشوار است
−احتمال طوفان تلهمتری در بالای سر
تصورات نادرست رایج
افسانه
نظارت بر سریهای زمانی میتواند تک تک تغییرات جزئی در رفتار سیستم را ثبت کند.
واقعیت
از آنجا که نظارت بر سریهای زمانی به نظرسنجی مبتنی بر فاصله زمانی متکی است، هرگونه افزایش ناگهانی عملکرد که بین دو چرخه scrape رخ میدهد و کاملاً برطرف میشود، برای داشبوردهای شما کاملاً نامرئی خواهد بود.
افسانه
تلهمتری مبتنی بر رویداد، جایگزینی مقرونبهصرفه برای تجمیع لاگهای سنتی است.
واقعیت
ذخیره تک تک رویدادهای سیستم با ابردادههای متنی کامل میتواند به سرعت بسیار گران شود، و اغلب هزینهای بسیار بیشتر از یک موتور متریک سری زمانی بهینه شده در طول بارهای عملیاتی اوج دارد.
افسانه
شما باید یک روش را انتخاب کنید و آن را منحصراً در زیرساخت خود مستقر کنید.
واقعیت
تنظیمات رصدپذیری سازمانی مدرن تقریباً همیشه هر دو سیستم را با هم ترکیب میکنند و از دادههای سری زمانی برای داشبوردهای سلامت سطح بالا و سیگنالهای مبتنی بر رویداد برای ردیابی خطاهای تراکنش خاص استفاده میکنند.
افسانه
ابزارهای مانیتورینگ مبتنی بر رویداد، درصد دسترسیپذیری سیستم شما را بهطور خودکار محاسبه میکنند.
واقعیت
جریانهای رویداد فقط میدانند چه زمانی اتفاق میافتند، به این معنی که فاقد ریتم ثابت مورد نیاز برای محاسبه آسان زمان روشن بودن سیستم هستند. تولید معیارهای دسترسی معمولاً نیاز به تبدیل آن رویدادهای گسسته به قالب سری زمانی پیوسته دارد.
سوالات متداول
آیا میتوانم از پرومتئوس برای وظایف مانیتورینگ رویدادمحور استفاده کنم؟
نه به طور مؤثر، زیرا پرومتئوس به طور هدفمند از ابتدا به عنوان یک موتور اندازهگیری سری زمانی مبتنی بر pull ساخته شده است. تلاش برای مجبور کردن آن به مدیریت رویدادهای حالت به صورت جداگانه، مدل ذخیرهسازی داخلی آن را که برای اعداد float64 به جای بارهای رویداد غنی و پر از متن طراحی شده است، تحت الشعاع قرار خواهد داد.
چرا نظارت مبتنی بر رویداد، برنامهریزی ظرفیت را پیچیده میکند؟
برنامهریزی ظرفیت نیازمند یک دیدگاه پیوسته و تاریخی از میزان استفاده از منابع است تا الگوهای مصرف جاری را شناسایی کرده و نیازهای زیرساختی آینده را پیشبینی کند. دادههای رویداد پراکنده و نامنظم هستند و محاسبه خطوط مبنای هموار لازم برای پیشبینی بلندمدت را از نظر ریاضی خستهکننده میکنند.
وقتی یک سیستم به طور کامل از کار میافتد، چه اتفاقی برای مانیتورهای رویدادمحور میافتد؟
اگر کل یک سرور یا لینک شبکه از کار بیفتد، یک سیستم مبتنی بر رویداد ممکن است ارسال رویدادها را به طور کلی متوقف کند، که میتواند به طرز گمراهکنندهای مانند یک سیستم کاملاً سالم به نظر برسد. به همین دلیل است که تیمها معماریهای رویداد را با ضربان قلبهای سری زمانی ساده میپوشانند تا مطمئن شوند که پلتفرم زیرین هنوز نفس میکشد.
کدام سبک مانیتورینگ برای توابع بدون سرور مانند AWS Lambda مناسبتر است؟
مانیتورینگ مبتنی بر رویداد به زیبایی با محیطهای بدون سرور سازگار است زیرا توابع کوتاهمدت هستند و به سرعت از کار میافتند. اسکریپرهای سری زمانی سنتی اغلب این اجراهای گذرا را به طور کامل از دست میدهند، در حالی که رویدادهای مبتنی بر فشار، چرخه عمر کامل زمان اجرا را در لحظه شروع تابع ثبت میکنند.
گردشهای کاری اشکالزدایی بین این دو روش تلهمتری چه تفاوتی دارند؟
وقتی یک مهندس با دادههای سری زمانی اشکالزدایی میکند، به رگرسیونهای کلی نگاه میکند، مانند شناسایی یک پنجره زمانی که درصد خطا در آن افزایش یافته است. با دادههای مبتنی بر رویداد، مهندس مستقیماً رد تراکنش منحصر به فرد را بررسی میکند تا ببیند دقیقاً کدام فراخوانی API توالی عملیاتی را مختل کرده است.
آیا تلهمتری مبتنی بر رویداد بر عملکرد برنامه تأثیر میگذارد؟
اگر پیکربندی ضعیفی داشته باشد، میتواند این اتفاق بیفتد، زیرا ارسال همزمان ساختارهای سنگین بار از مسیر اصلی برنامه شما، باعث تأخیر در پردازش میشود. برای کاهش این خطر، توسعهدهندگان معمولاً ثبت وقایع را به سرویسهای پسزمینه یا صفهای پیام ناهمگام واگذار میکنند تا خطوط کاربرپسند سریع بمانند.
بهترین راه برای مدیریت دادههای با کاردینالیتی بالا مانند شناسههای کاربری چیست؟
دادههای با کاردینالیتی بالا، پایگاههای داده سری زمانی سنتی را میشکنند، زیرا هر ترکیب برچسب منحصر به فرد، یک فایل ردیابی کاملاً جدید ایجاد میکند و حجم زیادی از حافظه را مصرف میکند. ساختارهای مبتنی بر رویداد این محدودیت را ندارند و میلیونها شناسه کاربری منحصر به فرد را به راحتی مدیریت میکنند، زیرا هر رویداد به عنوان یک ورودی لاگ جداگانه در نظر گرفته میشود.
آستانههای هشدار بین معیارها و رویدادها چگونه متفاوت هستند؟
هشدارهای معیار به روندهای ریاضی متکی هستند، مانند فعال شدن زمانی که میانگین نرخ خطا به مدت ده دقیقه متوالی بالای پنج درصد باقی بماند. هشدارهای رویداد دودویی و صریح هستند و بلافاصله فعال میشوند زیرا نوع خاصی از رویداد خرابی بحرانی در جریان دادهها ظاهر شده است.
حکم
اگر اهداف اصلی شما مصورسازی داشبورد، پیشبینی ظرفیت و ردیابی سلامت عمومی زیرساخت در درازمدت است، مانیتورینگ سری زمانی را انتخاب کنید. هنگام ساخت میکروسرویسهای جداشده، خطوط لوله حسابرسی بلادرنگ یا سیستمهای خوددرمان خودکار که باید فوراً به ناهنجاریهای نرمافزاری خاص واکنش نشان دهند، به مانیتورینگ رویدادمحور روی آورید.