در مسیر Observability، استک ویکتوریا (قسمت ششم)

در ادامه‌ی پست‌های قبلی تو این پست داریم می‌ریم سمت کامپوننت‌‌های استک ویکتوریا و یکم در مورد این‌که هر کدوم چی هستن و چه کمکی به ما می‌کنند می‌خواهیم صحبت کنیم.

استک victoria:

 

• ویکتوریامتریکس چیه و چه ویژگی‌هایی داره؟

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

تمام دیتای اون توی دایرکتوری که با فلگ storageDataPath – مشخص میشه، قرار میگیره.

یک امکان دیگه ای که بهمون میده بک‌آپ گرفتن راحت و سریع با استفاده از ابزارهای vmbackup و vmrestore هست.

از طرفی ویکتوریامتریکس از MetricsQL استفاده میکنه که به نوعی اومده یه لایه بالاتر از PromQL کاربردها رو پیشرفته تر کرده و توسعه داده.

میتونه اصطلاحا یه global query view بهمون بده یعنی مثلا از چنتا پرومتئوس هم دیتا بیاد سمتش ولی با یه کوئری همه‌ی این دیتا گرفته بشه.

توی اسکیل های بزرگ مخصوصا جاهایی که در اردر میلیون هست تعداد دیتای تایم سریز یونیکی که داریدم ویکتوریا ادعا میکنه که به نسبت InfluxDB تا ده برابر و به نسبت پرومتئوس و Thanos و Cortex تا هفت برابر کمتر RAM مصرف میکنه.

ویکتوریا متریکس برای چالش‌های پیاده سازی هم فکر کرده و خودش رو بهینه کرده برای کار کردن روی استورج و دیسک های با latancy بالا و IOPS کمتر مثل دیسک‌های HDD و نتورک استورج‌هایی که کلادها ارائه میدن.

این ویژگی ها در کنار ساپورت کردن پروتکل‌های مختلف scraping، فراهم کردن امکان اینکه روی متریک‌ها دوباره لیبل بزنیم و متن باز بودن نسخه کلاستر این ابزار، باعث میشه که حتما ارزش اینکه بررسیش کنیم رو داشته باشه.

 

مقایسه VictoriaMetrics با Prometheus

 

همونطور که قبلتر توضیح دادم پرومتئوس پروژه‌ای بود که توی ساندکلاد شروع شد و به عنوان یه ابزار قدرتمند مانیتورینگ و آلرتینگ مختص دیتای تایم‌سریز توی محیط های بزرگ، توی CNCF رشد کرد و با قابلیت جذابی که توی جمع کردن دیتا از تعداد زیادی سورس به صورت همزمان و پردازش اونها داشت، تبدیل به ابزار محبوبی توی کامیونیتی دواپس شد. از طرفی ویکتوریا متریکس ابزاریه که روی بهینه بودنش و پرفورمنس بالاش زیاد کار شده و میتونه به عنوان دیتابیس ریموت در استفاده‌های بلند مدت به پرومتئوس هم سرویس بده و با قابلیت‌هایی که ارائه میده به ابزار جذابی تبدیل شده در ادامه سعی میکنم این دوتا ابزار رو توی زمینه های مختلف با هم مقایسه کنم:

• مقایسه پرفورمنس

تو جدول پایین مقایسه دیتای به دست اومده از node_exporter روی یک نود سینگل رو میبینید:

 

• مقایسه دیزاین و قابلیت اسکیل

 

طراحی پرومتئوس به شکلی هست که از مدل pull-based برای جمع آوری دیتا استفاده میکنه و دیزاینش دیپلویمنت سرویس مانیتورینگ رو ساده‌تر کرده در عین حال توانایی منیج کردن اسکیل‌های بالا رو داره ولی نیاز داره که تارگت‌هاشو بشناسه تا ازشون pull کنه. اما در سمت دیگه ویکتوریامتریکس میتونه از هر دو مدل pull-based و push-based پشتیبانی کنه و توی حجم‌های بزرگ دیتا و سناریوهایی که از نظر شبکه پیچیدگی بیشتری دارند هم به خوبی کار کنه و انعطاف پذیری بالاتری داشته باشه که این ویژگی‌ها باعث میشن که برای استفاده‌های لانگ ترم ابزار جذابی بشه. توی پست قبلی کامپوننت‌ها و دیزاین پرومتئوس رو بررسی کردیم حالا میریم سراغ ویکتوریا، اگه یه مقدار به شکل ساده به دیزاین ویکتوریا متریکس نگاه کنیم، گذشته از vmui و vmctl و آلرت و ایجنت توی کلاسترش سه تا کامپوننت اصلی داره، اولی اونیه که متریک هارو میگیره دومی اونیه که متریک هارو ذخیره میکنه و سومی اونیه که جواب کسایی که میخوان متریک هارو بخونن، میده

 

همونطور که در تصویر بالا میبینید مشتری‌های ویکتوریا مثل پرومتئوس از طریق یک لودبالانسر با کامپوننت vminsert ارتباط میگیرن و متریک‌هارو تحویل اون میدن. وظیفه vminsert این هست که دیتا رو بفرسته به کامپوننت stateful ویکتوریا که vmstorage هست تا اونجا ذخیره بشه. حالا اونیکه میخواد این دیتا رو برداره و نمایش بده از طریق لودبالانسر با کامپوننت vmselect ارتباط میگیره.

بالاتر گفتیم که ویکتوریا متریکس نسبت به پرومتئوس هنگامی که دیتای با کاردینالیتی بالا داریم، بهتر عمل میکنه و این یک مزیت هست. بذارید یه کم بیشتر بررسی کنیم که دقیقا یعنی چی و کجا این مساله خودش رو میتونه نشون بده.

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

 

مثلا متریک status_code توی مثال بالا میتونه پنج تا لیبل مختلف بگیره و کاردینالیتی اون پنج هست همینطور کاردیضنالیتی app دو هست، بنابراین برای متریک server_responses کاردینالی ده رو خواهیم داشت. هندل کردن این کاردینالیتی و این مثال برای پرومتئوس ممکن و ساده هست اما اگه متریک های اسم پاد یا آی پی های یه کلاستر کوبرنتیز رو داشته باشیم، pod_name و client_ip . اون وقت کاردینالیتی ممکنه پرومتئوس رو با مشکل مواجه کنه. مثلا اگه چنتا متریک با کاردینالیتی بالای ۱۰۰۰۰۰ داشته باشیم، پرومتئوس به خوبی عمل نمیکنه و مصرف RAM بسیار بالا میره.

به کمک هلم چارت‌های ویکتوریا در کنار ساختاری که داره که میتونیم به راحتی با استفاده از HPA توی کوبر vminsert های اون رو اسکیل کنیم و این ابزار رو روی کوبرنتیز دیپلوی کنیم.

• مقایسه فشرده سازی دیتا و استورج بهینه

پرومتئوس و ویکتوریامتریکس هر دو برای نگهداری دیتای تایم‌سریز از ترکیب مموری و دیسک استفاده میکنن. پرومتئوس بلافاصله بعد از اینکه دیتای تایم‌سریز رو pull کرد اون رو توی ‌RAM نگه میداره که این قسمت از دیتابیس توی پرومتئوس با نام head block شناخته میشه. بعد از اینکه دیتا به یک سایز مشخصی رسید یا زمان مشخصی از عمرش توی دیتابیس طی شد از هد بلاک به دیسک منتقل میشه که این پروسه رو بهش checkpointing real-time میگیم و برای نگهداری‌های بلندمدت‌تر دیتا به قسمتی از دیتابیس با اسم persistent block که روی دیسک هست منتقل میشه.

پرومتئوس بیشتر برای مانیتورینگ به صورت real-time آپتیمایز شده و برای نگهداری طولانی مدت دیتا استورج بهینه‌ای نیست و ابزارهای جانبی‌ای مثل Levitate و Thanos و Cortex هستن که میتونه برای این مساله ازشون کمک بگیره.

ویکتوریا متریکس هم از RAM استفاده میکنه برای اینکه دیتا رو قبل نوشتن توی دیسک بافر کنه و پرفورمنس نوشتنش رو بهتر کنه و در کنارش یه جورایی دیتای اخیر رو کش هم کنه و سریعتر پاسخ بده استفاده میکنه و نهایتا دیتا رو به دیسک میبره و با توجه به اینکه ویکتوریامتریکس ادعا میکنه که از الگوریتم فشرده سازی‌ای استفاده میکنه که توی بنچمارک تا ۱۰ برابر فشرده سازی بیشتری رو نسبت به الگوریم پرومتئوس داشته، کاملا میتونه مزیت خودش رو توی نگهداری‌های بلند مدت نشون بده.

• زبان کوئری

پرومتئوس از ( PromQL ( Prometheus Query Language استفاده میکنه که امکان سلکت کردن و ترکیب دیتا تایم‌سریز رو میده تا توسعه دهنده‌ها بتونن با انعطاف‌پذیری بالایی با متریک‌ها کار کنن. با پرام‌کیو‌ال میشه دیتا رو فیلتر کرد، ترندهارو پیدا کرد، درصد گرفت، میانگین گرفت و … در سمت دیگه ویکتوریامتریکس اومده و یه جورایی PromQL رو اکستند کرده و از MetricsQL استفاده میکنه، یعنی علاوه بر اینکه همه دستورات و قابلیت های PromQL رو پشتیبانی میکنه و اصطلاحا backward compatible هست یه سری قابلیت‌ها و سینتکس‌ها اضافه هم برای کوئری‌های پیچیده تر و تجربه کاربری بهتر ارائه میده.

• مقایسه ingestion rate

اینجسشن‌ ریت ( یا حالا اینجسچن واسه رفقای حساس ترمون ) در واقع معیاری هست که توی زمینه دیتا یه جورایی برای ما مشخص میکنه که سیستم‌مون توانایی پردازش چه حجمی از دیتای تله‌متری رو به صورت کارآمد داره.

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

اما ویکتوریامتریکس طراحی شده تا در مصرف منابع افیشنت باشه، این ابزار ادعا میکنه که در مواجهه با حجم دیتای برابر نسبت به پرومتئوس CPU و RAM و دیسک کمتری مصرف میکنه و این قابلیتش امکان پردازش سریعتر نسبت به پرومتئوس روی سخت افزار یکسان رو هم بهش داده و جدای از طراحی ویکتوریا متریکس میتونه از روش push هم دیتا رو جمع کنه که مخصوصا در مورد دیتا با کاردینالیتی بالا ( یعنی دیتایی که مقادیری که ممکنه بگیره زیاد هستن مثلا id که شماره های زیادی میتونه باشه ) یه مزیت برای ویکتوریا متریکس محسوب میشه.

• مقایسه HA

پرومتئوس خودش HA نداره! یعنی به صورت native این امکان رو فراهم نمیکنه ولی میشه با یه مقدار تلاش و پشتکار دوتا ازش بالا آورد و یه کارایی کرد، در طرف دیگه ویکتوریا نه تنها اصلا برای این مساله طراحی شده و بهش فکر کرده، بلکه هم خودش و هم کامیونیتی انسیبل کلاسترشم زدن تا مطمئن باشید دیتاتون لاست نمیشه.

 

• مقایسه سازگاری با گرافانا

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

• مقایسه سازگاری با کوبرنتیز

دوتا موضوع هست اول اینکه آیا پرومتئوس و ویکتوریا میتونن خودشون روی کوبر دیپلوی بشن؟ که جواب بله هست و موضوع دوم اینه که میتونن متریک‌های کوبر رو مانیتور کنن؟ که بازم جواب بله هست

پرومتئوس که دیگه تو CNCF بغل دست کوبرنتیز هست و به صورت native از سرویس دیسکاوری کوبر ساپورت میکنه و میتونه به صورت خودکار متریک‌های سرویس‌ها و نودها و پادها رو بگیره.

برای دیپلوی شدن پرومتئوس روی انوایرومنت کوبر هم، میتونید هم از هلم چارتش استفاده کنید و هم از Prometheus Operator که دیپلوی و کانفیگ کردن پرومتئوس و آلرت منیجر و بقیه کامپوننت هارو ساده کرده و اگه با مفاهیم کوبرنتیز آشنا هستید، امکان دیپلوی کردن پرومتئوس و آلرت منیجر به صورت کاستوم ریسورس CRD توی کوبر فراهم هست.

در نهایت استفاده از Prometheus یا VictoriaMetrics به نیاز پروژه شما بستگی داره. Prometheus با قابلیت‌های جستجوی قدرتمندی که داره و قابلیت ادغام دقیق با سایر پروژه‌های CNCF، ممکنه برای محیط‌هایی که این ویژگی‌ها در اونها ارزشمنده، مناسب تر باشه. از سوی دیگر، اگر مقیاس پذیری، فشرده سازی داده‌ها و در دسترس بودن بالا نگرانی های اصلی شما هستند، VictoriaMetrics می تونه انتخاب بهتری باشه. همیشه توصیه می شود قبل از تصمیم گیری در مورد یک راه حل، نیازها و محدودیت های نظارتی خود را به دقت ارزیابی کنید.

 

برای ران کردن اپلیکیشن ویکتوریا متریکس روی کوبرنتیز، راحت ترین راه استفاده از هلم چارت victoria-metrics-k8s-stack هست که یک operator روی کوبر برای ویکتوریا متریکس درست میکنه. یک استک کامل از ویکتوریا شامل vmagent و vmauth و vmalert و vmalertmanager و vmcluster هست که vmcluster کامپوننتی هست که از سه تا کامپوننت vmstorage و vmselect و vminsert تشکیل شده.

 

همانطور که در تصویر پایین مشخص هست درخواست کاربران ویکتوریا که مثلا گرافانا هست بعد از اینکه احراز هویت شدن به vmselect میرسه تا دیتایی که میخوان رو از vmstorage برای اونا بگیره و آماده کنه و تحویل بده. اما ایجنت ها توی کلاستر متریک هارو برای vminsert میفرستن تا در vmstorage ذخیره کنه و کامپوننت vmalert هم مثل گرافانا درخواست هاشو به vminsert میده تا درصورت نیاز بعد از انجام بررسی vmalertmanager رو تریگر کنه که از مشکلی که به وجود اومده مارو مطلع کنه.

 

• بررسی Victoria Metrics Anomaly Detection

ویکتوریا متریکس سرویسی با نام vmanomaly داره که میتونه پیوسته دیتای تایم‌سریز رو اسکن کنه و تغییراتی که غیرمنتظره هستن رو تشخیص بده و به صورت real-time تغییر در پترن دیتا رو متوجه بشه. vmanomaly این کار رو به کمک استفاده از مدل های ماشین لرنینگ که توسط کاربر قابل کانفیگ هست، انجام میده.

 

ویکتوریا متریکس با این ویژگی به صورت متناوب روی متریک هایی که یوزر براش مشخص کرده کوئری میزنه و anomaly score رو بر اساس اینکه دیتای جدید چقدر به پیش بینی ها شباهت داره و مورد انتظارمون هست، محاسبه میکنه و پس از آن یوزر میتونه روی این نمره ی ناهنجاری که بدست میاد آلرت تعریف کنه و در مقایسه با آلرت به روش قبلی آنومالی دیتکشن بیشتر اتوماتیک هست و یوزر کمتر نیاز هست که کارای منوآل انجام بده و راحت تر هست.

Note: vmanomaly is a part of enterprise package. You need to get a free trial license for evaluation.

طبق داک ویکتوریا به نظر میرسه که قابلیت آنومالی دیتکشن برای نسخه enterprise فعال هست.

میتونید الگوریتم های مختلف رو به vmanomaly بدید و به طور کلی همه پارامتر های مختلف این سرویس مثل model و schedule و input-output توی یک فایل کانفیگ تعریف میکنیم.

هر فایل کانفیگ فقط از یک مدل میتونه ساپورت کنه ولی میتونید vmanomaly های مختلف با فایل کانفیگ های مختلف رو به صورت پارالل اجرا کنید.

چهار بخش هست که نیازه اون هارو توی config file برای vmanomaly تعریف کنیم:

• Scheduler

تو این قسمت نحوه ساخت و اجرای اینترفیس و بازه زمانیکه مدل train میشه رو تعریف میکنیم.

• Models

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

• Reader

تو این قسمت مشخص میکنیم که مدل به چه شکل دیتا رو بخونه و اون دیتا کجا قرار داره

• Writer

توی این قسمت هم مشخص میکنیم که کجا و به چه شکل دیتایی که جنریت میکنه رو بنویسه

• Monitoring

مورد آخر که به صورت آپشنال هم هست و میتونیم تعریفش نکنیم مانیتورینگ هست که توی این مورد مشخص میکنیم که مانیتور به چه صورت برای سرویس آنومالی کار کنه.

توی پست‌های بعدی بیشتر ابزارهای مانیتورینگ و Observability رو بررسی می‌کنیم و کنار هم یاد میگیرم.

مراقب خودتون باشید.