در ادامهی پستهای قبلی تو این پست داریم میریم سمت کامپوننتهای استک ویکتوریا و یکم در مورد اینکه هر کدوم چی هستن و چه کمکی به ما میکنند میخواهیم صحبت کنیم.
عکس عمو بلاگ پست""""
خب یه مروری کنیم پستهای قبلی رو:
دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسهاش کنیم.
در مسیر Observability، میمیر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمهدستی واسه تستهامون داشته باشیم.
کامپوننتهای کوبر ( قسمت سوم ) توی این پست کامپوننتهای مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.
پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.
ورکلودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورکلود کوبر رو بررسی کردیم.
اگه لازم شد کوبر خودش گنده میشه! ( قسمت ششم ) توی این پست در مورد سه نوع ورکلود مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.
نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.
استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.
پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع probe ها توی کوبرنتیز توضیح دادیم.
پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفتهتری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.
اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبههای مختلف امنیت در کوبرنتیز توضیح دادیم.
کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.
دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روشهای مختلفی که داره توضیح دادیم و همچنین تفاوت روشهای مختلف تقسیم منابع در کلاسترها را بررسی کردیم.
مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالشهای مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.
هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگیها و کاربردهاش توضیح دادیم.
سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.
نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.
نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.
نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راهاندازی کنیم.
توصیه میکنم که حتما این پستها رو هم مطالعه کنید. بریم که ادامه بدیم.
استک 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 رو بررسی میکنیم و کنار هم یاد میگیرم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
