VictoriaMetrics و نظارت بر ابر خصوصی. پاول کولوبایف

VictoriaMetrics یک DBMS سریع و مقیاس پذیر برای ذخیره و پردازش داده ها در قالب یک سری زمانی است (یک رکورد یک زمان و مجموعه ای از مقادیر مربوط به این زمان را تشکیل می دهد، به عنوان مثال، از طریق نظرسنجی دوره ای وضعیت سنسورها به دست می آید. یا جمع آوری معیارها).

نام من پاول کولوبایف است. DevOps، SRE، LeroyMerlin، همه چیز مانند کد است - همه چیز درباره ما است: درباره من و سایر کارمندان LeroyMerlin.

https://bit.ly/3jf1fIK

یک ابر مبتنی بر OpenStack وجود دارد. یک لینک کوچک به رادار فنی وجود دارد.

این بر اساس آهن Kubernetes، و همچنین بر روی تمام خدمات مرتبط به OpenStack و ورود به سیستم ساخته شده است.

این طرحی است که ما در توسعه داشتیم. وقتی همه اینها را توسعه دادیم، اپراتور Prometheus را داشتیم که داده ها را در خود خوشه K8 ذخیره می کرد. او به طور خودکار آنچه را که باید تمیز شود پیدا می کند و آن را زیر پای خود می گذارد.

ما باید تمام داده ها را به خارج از خوشه Kubernetes منتقل کنیم، زیرا اگر اتفاقی بیفتد، باید بفهمیم چه چیزی و کجا.

اولین راه حل این است که وقتی از طریق مکانیسم فدراسیون به خوشه Kubernetes می رویم، از فدراسیون زمانی استفاده می کنیم که Prometheus شخص ثالثی داریم.

اما در اینجا چند مشکل جزئی وجود دارد. در مورد ما، مشکلات از زمانی شروع شد که ما 250 متریک داشتیم و وقتی 000 متریک بود متوجه شدیم که نمی‌توانیم اینطور کار کنیم. ما scrape_timeout را به 400 ثانیه افزایش دادیم.

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

همه نمودارهایی را می‌دانند که وقتی بخشی از داده‌ها از دست می‌رود، دریافت می‌کنیم. گرافیکش پاره شده و ما راضی نیستیم.

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

به عنوان مثال، فقط آنها را بر اساس نام ببرید و خرد کنید. این نیز قابل استفاده است، اما ما تصمیم گرفتیم که ادامه دهیم.

اکنون باید این خرده ها را به نحوی پردازش کنیم. شما می توانید از promxy استفاده کنید، که در ناحیه خرد شده فرود می آید و داده ها را چند برابر می کند. با دو خرده به عنوان یک نقطه ورود کار می کند. این را می توان از طریق promxy پیاده سازی کرد، اما در حال حاضر بسیار پیچیده است.

گزینه اول - ما می خواهیم مکانیزم فدراسیون را کنار بگذاریم، زیرا بسیار کند است.

توسعه دهندگان Prometheus به صراحت می گویند: "بچه ها، از TimescaleDB دیگر استفاده کنید، زیرا ما از ذخیره سازی طولانی مدت معیارها پشتیبانی نمی کنیم." این وظیفه آنها نیست.

ما روی یک تکه کاغذ می نویسیم که هنوز باید آن را در بیرون تخلیه کنیم تا همه چیز را در یک مکان ذخیره نکنیم.

دومین عیب مصرف حافظه است. بله، من می دانم که بسیاری می گویند که در سال 2020 یک دو گیگابایت حافظه ارزش یک پنی دارد، اما با این وجود.

اکنون ما یک محیط توسعه و توسعه داریم. در توسعه دهنده، این حدود 9 گیگابایت در هر 350 متریک است. در پرود، این 000 گیگابایت با متریک کوچک 14 است. در عین حال، ما فقط 780 دقیقه زمان نگهداری داریم. این بد است. و حالا دلیلش را توضیح خواهم داد.

ما یک محاسبه می کنیم، یعنی با یک و نیم میلیون متریک، و در حال حاضر به آنها نزدیک شده ایم، در مرحله طراحی، 35-37 گیگابایت حافظه دریافت می کنیم. اما در حال حاضر با 4 میلیون متریک، حدود 90 گیگابایت حافظه در حال حاضر مورد نیاز است. یعنی طبق فرمول ارائه شده توسط توسعه دهندگان Prometheus محاسبه شد. ما به همبستگی نگاه کردیم و متوجه شدیم که نمی‌خواهیم چند میلیون برای یک سرور فقط برای نظارت بپردازیم.

ما نه تنها تعداد ماشین ها را افزایش خواهیم داد، بلکه خود ماشین های مجازی را نیز رصد می کنیم. بنابراین هر چه تعداد ماشین های مجازی بیشتر باشد، متریک ها در انواع مختلف و غیره بیشتر می شود که از نظر متریک رشد ویژه ای از خوشه خود خواهیم داشت.

با فضای دیسک، همه چیز در اینجا غم انگیز نیست، اما من می خواهم آن را بهبود بخشم. ما در مجموع 15 گیگابایت در 120 روز دریافت کردیم که 100 گیگ داده فشرده است، 20 گیگ داده غیر فشرده، اما شما همیشه کمتر می خواهید.

بر این اساس، ما یک نکته دیگر را یادداشت می‌کنیم - این مصرف زیادی از منابع است که ما هنوز می‌خواهیم آن را ذخیره کنیم، زیرا نمی‌خواهیم خوشه نظارتی ما نسبت به خوشه ما که OpenStack را مدیریت می‌کند، منابع بیشتری بخورد.

یک معایب دیگر پرومتئوس وجود دارد که ما آن را برای خود شناسایی کرده ایم، این حداقل نوعی محدودیت حافظه است. با پرومتئوس، اینجا همه چیز خیلی بدتر است، زیرا او اصلاً چنین پیچ و تاب هایی ندارد. استفاده از محدودیت docker نیز یک گزینه نیست. اگر ناگهان RAF شما سقوط کرده باشد و 20-30 گیگابایت وجود داشته باشد، زمان زیادی طول می کشد تا بالا بیاید.

این یکی دیگر از دلایلی است که Prometheus برای ما مناسب نیست، یعنی نمی توانیم مصرف حافظه را محدود کنیم.

امکان ارائه چنین طرحی وجود دارد. ما به این طرح برای سازماندهی یک خوشه HA نیاز داریم. ما می خواهیم معیارهای ما در هر زمان و هر مکان در دسترس باشد، حتی اگر سروری که این معیارها را ذخیره می کند خراب شود. و بنابراین ما باید چنین طرحی را بسازیم.

این طرح می گوید که ما تکثیر خرده ها و بر این اساس هزینه های منابع مصرفی را تکرار خواهیم کرد. می توان آن را تقریباً به صورت افقی مقیاس کرد، اما با این وجود مصرف منابع جهنمی خواهد بود.

معایب به ترتیب، به شکلی که ما آنها را برای خود نوشتیم:

• به بارگذاری معیارها در خارج نیاز دارد.
• مصرف بالای منابع
• شما نمی توانید مصرف حافظه را محدود کنید.
• اجرای پیچیده و با منابع فشرده HA.

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

ما ملزومات اضافی را برای خود که به آن نیاز داریم شناسایی کرده ایم. این:

• این پشتیبانی از promql است، زیرا قبلاً چیزهای زیادی برای Prometheus نوشته شده است: پرس و جوها، هشدارها.
• و سپس ما Grafana را داریم که قبلاً به همین شکل تحت Prometheus به عنوان یک باطن نوشته شده است. من نمی خواهم داشبوردها را بازنویسی کنم.
• ما می خواهیم یک معماری HA معمولی بسازیم.
• ما می خواهیم مصرف هر منبعی را کاهش دهیم.
• یک تفاوت ظریف دیگر وجود دارد. ما نمی توانیم از انواع مختلف سیستم های ابری برای جمع آوری معیارها استفاده کنیم. ما نمی دانیم در حال حاضر چه چیزی به این معیارها خواهد رسید. و از آنجایی که هر چیزی می تواند به آنجا پرواز کند، ما باید خود را به مکان محلی محدود کنیم.

انتخاب کوچک بود. ما همه چیزهایی را که در آن تجربه داشتیم جمع آوری کرده ایم. ما به صفحه Prometheus در بخش ادغام نگاه کردیم، مجموعه ای از مقالات را خواندیم، به آنچه به طور کلی در دسترس است نگاه کردیم. و برای خودمان، VictoriaMetrics را به عنوان جایگزینی برای Prometheus انتخاب کردیم.

چرا؟ زیرا:

• قادر به promql.
• یک معماری مدولار وجود دارد.
• به هیچ تغییری در Grafana نیاز ندارد.
• و مهمتر از همه، ما احتمالاً یک ذخیره‌سازی معیارها را در شرکت خود به عنوان یک سرویس ارائه خواهیم داد، بنابراین از قبل به دنبال انواع محدودیت‌ها هستیم تا کاربران بتوانند از تمام منابع خوشه به روشی محدود استفاده کنند، زیرا این شانس وجود دارد. که چند اجاره ای خواهد شد.

ما اولین مقایسه را انجام می دهیم. همان پرومتئوس را داخل خوشه می گیریم، پرومتئوس خارجی به سمت آن می رود. ما از طریق remoteWrite VictoriaMetrics اضافه می کنیم.

من فوراً رزرو می کنم که در اینجا ما شاهد افزایش اندکی در مصرف CPU از VictoriaMetrics هستیم. ویکی VictoriaMetrics می گوید که کدام پارامترها مناسب تر هستند. ما آنها را بررسی کردیم. آنها به خوبی مصرف CPU را کاهش دادند.

در مورد ما، مصرف حافظه Prometheus، که در یک خوشه Kubernetes قرار دارد، افزایش قابل توجهی نداشت.

ما دو منبع داده از یک داده را با هم مقایسه می کنیم. در پرومتئوس، ما همه داده‌های گمشده را می‌بینیم. همه چیز در VictoriaMetrics خوب است.

نتایج آزمایشات با فضای دیسک. ما در Prometheus در مجموع 120 گیگابایت داریم. در VictoriaMetrics، ما در حال حاضر 4 گیگابایت در روز دریافت می کنیم. مکانیسم کمی متفاوت از آنچه شما در پرومتئوس به دیدن آن عادت دارید وجود دارد. یعنی داده ها در حال حاضر به مدت یک روز، به مدت نیم ساعت به خوبی فشرده شده اند. آنها قبلاً در یک روز و در نیم ساعت به خوبی درو می شوند ، علیرغم این واقعیت که بعداً داده ها ادغام می شوند. در نتیجه در فضای دیسک صرفه جویی کردیم.

همچنین در مصرف منابع حافظه صرفه جویی می کنیم. در زمان آزمایش‌ها، ما Prometheus را روی یک ماشین مجازی مستقر کردیم - 8 هسته، 24 گیگابایت. پرومتئوس تقریباً همه چیز را می خورد. او روی OOM Killer افتاد. در همان زمان، تنها 900 معیار فعال در آن ریخته شد. این حدود 000-25 متریک در ثانیه است.

VictoriaMetrics روی یک ماشین مجازی دو هسته ای با 8 گیگابایت رم در حال اجرا بود. ما موفق شدیم VictoriaMetrics را با بهینه سازی برخی چیزها در یک دستگاه 8 گیگابایتی به خوبی کار کند. در نتیجه، ما در 7 گیگابایت نگه داشتیم. در همان زمان، سرعت تحویل محتوا، یعنی معیارها، حتی بالاتر از Prometheus بود.

CPU خیلی بهتر از Prometheus است. در اینجا Prometheus 2,5 هسته مصرف می کند و VictoriaMetrics فقط 0,25 هسته مصرف می کند. در ابتدا - 0,5 هسته. همانطور که ادغام می شود، به یک هسته می رسد، اما این بسیار، بسیار نادر است.

در مورد ما، انتخاب به دلایل واضح بر روی VictoriaMetrics افتاد، ما می خواستیم در پول خود صرفه جویی کنیم و پس انداز کردیم.

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

در اینجا من فوراً رزرو می کنم ، ما VictoriaMetrics را به عنوان مخزن معیارها در نظر می گیریم. اما از آنجایی که ما به احتمال زیاد VictoriaMetrics را به عنوان فضای ذخیره‌سازی برای تمام Leroy ارائه خواهیم کرد، باید کسانی را که از این خوشه استفاده می‌کنند محدود کنیم تا آن را در اختیار ما قرار ندهند.

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

و همچنین یک گزینه عالی وجود دارد که به شما امکان می دهد مصرف حافظه را محدود کنید، بنابراین ما می توانیم تعادلی را پیدا کنیم که به ما امکان می دهد سرعت عادی و مصرف منابع کافی داشته باشیم.

منهای یک نقطه دیگر، یعنی ما نقطه را خط می زنیم - نمی توانید مصرف حافظه را محدود کنید.

در اولین تکرارها، گره واحد VictoriaMetrics را آزمایش کردیم. سپس به سراغ نسخه خوشه VictoriaMetrics می رویم.

در اینجا ما در موضوع جداسازی سرویس‌های مختلف در VictoriaMetrics بسته به اینکه روی چه چیزی بچرخند و چه منابعی مصرف خواهند کرد، دست آزاد داریم. این یک راه حل بسیار منعطف و راحت است. خودمان استفاده کرده ایم.

اجزای اصلی نسخه خوشه VictoriaMetrics vmstsorage هستند. ممکن است عدد N وجود داشته باشد. در مورد ما، 2 مورد از آنها وجود دارد.

و vminsert وجود دارد. این یک سرور پراکسی است که به ما امکان می‌دهد: بین همه ذخیره‌سازی‌هایی که به او گفته‌ایم، اشتراک‌گذاری را ترتیب دهیم، و اجازه می‌دهد یک کپی دیگر، یعنی هم اشتراک‌گذاری و هم یک ماکت داشته باشید.

Vminsert از پروتکل های OpenTSDB، Graphite، InfluxDB و remoteWrite Prometheus پشتیبانی می کند.

vmselect هم هست. وظیفه اصلی آن این است که به vmstorage بروید، داده ها را از آنها دریافت کنید، این داده ها را حذف کنید و به مشتری بدهید.

یک چیز فوق العاده مانند vmagent وجود دارد. ما واقعا او را دوست داریم. این به شما امکان می دهد دقیقاً مانند Prometheus پیکربندی کنید و همچنان همه چیز را درست مانند Prometheus انجام دهید. یعنی متریک ها را از موجودیت ها و سرویس های مختلف جمع آوری کرده و به vminsert می فرستد. سپس همه چیز به شما بستگی دارد.

سرویس عالی دیگر vmalert است که به شما امکان می دهد از VictoriaMetrics به عنوان یک Backend استفاده کنید، داده های پردازش شده را از vminsert دریافت کنید و داده های پردازش شده را به vmselect ارسال کنید. خود هشدارها و همچنین قوانین را پردازش می کند. در مورد هشدارها از طریق alertmanager یک هشدار دریافت می کنیم.

یک جزء wmauth وجود دارد. ما احتمالاً از آن استفاده خواهیم کرد و شاید نه (هنوز در این مورد تصمیم نگرفته ایم) به عنوان یک سیستم مجوز برای نسخه های چند اجاره ای خوشه ها. از remoteWrite برای Prometheus پشتیبانی می‌کند و می‌تواند بر اساس url یا بهتر است بگوییم قسمت دوم آن، جایی که می‌توانید یا نمی‌توانید بنویسید، مجوز دهد.

vmbackup، vmrestore نیز وجود دارد. این در واقع بازیابی و پشتیبان گیری از تمام داده ها است. قادر به S3، GCS، فایل.

اولین تکرار خوشه ما در دوران قرنطینه انجام شد. در آن زمان، هیچ نسخه‌ای وجود نداشت، بنابراین تکرار ما شامل دو خوشه متفاوت و مستقل بود که داده‌ها را از طریق remoteWrite دریافت می‌کردیم.

در اینجا من رزرو می کنم که وقتی از VictoriaMetrics Single Node به VictoriaMetrics Cluster Version تغییر می کنیم، همچنان در همان منابع مصرف شده باقی می ماندیم، یعنی منبع اصلی حافظه است. تقریباً به این ترتیب داده های ما توزیع شد، یعنی مصرف منابع.

یک ماکت قبلاً در اینجا اضافه شده است. ما همه اینها را در یک خوشه نسبتا بزرگ ترکیب کرده ایم. همه داده ها هم خرد شده و هم تکرار می شوند.

کل خوشه دارای N نقطه ورودی است، یعنی Prometheus می تواند داده ها را از طریق HAPROXY اضافه کند. اینجا نقطه ورود ماست. و از طریق این نقطه ورود می توانید با Grafana وارد شوید.

در مورد ما، HAPROXY تنها پورتی است که پراکسی‌ها را انتخاب، درج و سایر خدمات را در این خوشه قرار می‌دهد. در مورد ما، ایجاد یک آدرس غیرممکن بود، ما مجبور بودیم چندین نقطه ورودی ایجاد کنیم، زیرا خود ماشین های مجازی، که خوشه VictoriaMetrics روی آنها اجرا می شود، در مناطق مختلف یک ارائه دهنده ابر قرار دارند، یعنی در داخل ابر ما نیستند. ، اما بیرون

ما یک هشدار داریم. ما از آن استفاده می کنیم. ما از alertmanager Prometheus استفاده می کنیم. ما از Opsgenie و Telegram به عنوان کانال ارسال هشدار استفاده می کنیم. در تلگرام، آنها از dev می ریزند، شاید چیزی از prod، اما بیشتر شبیه چیزی آماری است که مهندسان به آن نیاز دارند. و Opsgenie انتقادی است. اینها تماس ها، مدیریت حوادث هستند.

سوال قدیمی: "چه کسی نظارت را نظارت می کند؟". در مورد ما، مانیتورینگ خود نظارت را نظارت می کند، زیرا ما از vmagent در هر گره استفاده می کنیم. و از آنجایی که گره های ما در مراکز داده مختلف یک ارائه دهنده قرار دارند، هر مرکز داده کانال خاص خود را دارد، آنها مستقل هستند و حتی اگر مغز تقسیم شود، باز هم هشدارها را دریافت خواهیم کرد. بله، تعداد بیشتری از آنها وجود خواهد داشت، اما بهتر است هشدارهای بیشتری نسبت به عدم دریافت کنید.

ما لیست خود را با اجرای HA به پایان می رسانیم.

و همچنین می‌خواهم به تجربه ارتباط با جامعه VictoriaMetrics اشاره کنم. معلوم شد که خیلی مثبت است. بچه ها پاسخگو هستند آنها سعی می کنند در هر موردی که ارائه می شود، عمیق بشوند.

من مشکلاتی را در GitHub ایجاد کردم. خیلی سریع حل شدند. چند موضوع دیگر وجود دارد که به طور کامل بسته نشده اند، اما من قبلاً می توانم از روی کد متوجه شوم که کار در این راستا در حال انجام است.

درد اصلی در طول تکرارها برای من این بود که اگر گره را قطع کنم، در 30 ثانیه اول vminsert نمی توانست بفهمد که هیچ باطنی وجود ندارد. حالا دیگر تصمیم گرفته شده است. و به معنای واقعی کلمه در یک یا دو ثانیه، داده‌ها از تمام گره‌های باقی‌مانده گرفته می‌شود و درخواست از انتظار برای آن گره از دست رفته متوقف می‌شود.

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

پیشنهادهایی برای بهبود اجرای خوشه وجود دارد. من آنها را در بالا شرح داده ام.

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

• ما در هنگام استفاده از پرومته، مانند برخی از همکارانمان، درد را می شناسیم.
• ما VictoriaMetrics را برای خود انتخاب کردیم.
• هم به صورت عمودی و هم افقی به خوبی مقیاس می شود.
• ما می توانیم اجزای مختلف را در تعداد متفاوتی از گره ها در خوشه توزیع کنیم، آنها را از نظر حافظه محدود کنیم، حافظه اضافه کنیم و غیره.

ما از VictoriaMetrics در خانه استفاده خواهیم کرد، زیرا واقعاً آن را دوست داشتیم. اینجاست که چه اتفاقی افتاده و چه اتفاقی افتاده است.

https://t.me/VictoriaMetrics_ru1

چند کد qr برای چت VictoriaMetrics، مخاطبین من، رادار فنی LeroyMerlin.

منبع: www.habr.com