انتخاب یک ذخیره سازی داده برای Prometheus: Thanos vs VictoriaMetrics

سلام به همه. در زیر رونوشت آمده است گزارش از Big Monitoring Meetup 4.

تیتان فرزند پاپتوس - یک سیستم نظارتی برای سیستم ها و سرویس های مختلف که با کمک آن مدیران سیستم می توانند اطلاعات مربوط به پارامترهای فعلی سیستم ها را جمع آوری کرده و هشدارهایی را برای دریافت اعلان ها در مورد انحرافات در عملکرد سیستم ها تنظیم کنند.

این گزارش شامل یک مقایسه خواهد بود Thanos и ویکتوریا متریکس - پروژه‌هایی برای ذخیره‌سازی بلندمدت معیارهای Prometheus.

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

محدودیت های پرومتئوس:

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

راه حلی برای این مشکلات/چالش ها؟

راه حل ها عبارتند از:

• Thanos
• ویکتوریا متریکس
• اوبر M3
• قشر

همه این راه حل ها برای ذخیره سازی از راه دور داده های جمع آوری شده توسط Prometheus هستند. آنها مشکل ذخیره سازی از راه دور از اسلاید قبلی را به روش های مختلف حل می کنند. در این ارائه من فقط در مورد دو راه حل اول صحبت خواهم کرد: Thanos и ویکتوریا متریکس.

برای اولین بار اطلاعاتی در مورد Thanos ظاهر شد توسط این لینک. معماری در آنجا شرح داده شده است Thanos و چگونه کار می کند.

Thanos داده‌هایی را که Prometheus ذخیره کرده بود در دیسک محلی می‌برد و در S3 کپی می‌کند. GCS یا به ذخیره سازی شی دیگری.

بنابراین Thanos یک نمای کلی پرس و جو ارائه می دهد. می توانید داده های ذخیره شده در ذخیره سازی اشیاء را از چندین نمونه Prometheus جستجو کنید.

Thanos از PromQL و Prometheus querying API.

Thanos از کد Prometheus برای ذخیره داده ها استفاده می کند.

Thanos توسط همان توسعه دهندگان Prometheus توسعه یافته است.

بر ویکتوریا متریکس. اینجا پیوند، جایی که ما برای اولین بار در مورد آن صحبت کردیم ویکتوریا متریکس.

VictoriaMetrics داده هایی را از چندین پرومتئوس دریافت می کند API نوشتن از راه دور پروتکل پشتیبانی شده توسط Prometheus

VictoriaMetrics یک نمای کلی پرس و جو ارائه می دهد، زیرا چندین نمونه Prometheus می توانند داده ها را در یک VictoriaMetrics بنویسند. بر این اساس، می توانید در مورد همه این داده ها پرس و جو کنید.

VictoriaMetrics نیز مانند Thanos، PromQL و Prometheus querying API را پشتیبانی می‌کند.

برخلاف Thanos، کد منبع VictoriaMetrics از ابتدا نوشته شده است و برای سرعت و مصرف منابع بهینه شده است.

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

تاریخچه تانوس در نوامبر 2017 آغاز شد، زمانی که اولین کامیت عمومی ظاهر شد. قبل از این، Thanos به صورت داخلی توسعه یافته بود improbable.io.

در ژوئن 2019 نسخه برجسته 0.5.0 منتشر شد که در آن حذف شده شایعات بی اساس پروتکل او از ثانوس حذف شد زیرا عملکرد خوبی نداشت. اغلب خوشه Thanos به درستی کار نمی کند، گره ها به دلیل پروتکل gossip به اشتباه به آن متصل می شوند. بنابراین تصمیم گرفتیم او را از آنجا حذف کنیم. به نظر من این تصمیم درستی است.

در همان ژوئن 2019، آنها شماره درخواست را ارسال کردند 256 в بنیاد رایانش بومی ابر.

و بعد از چند ماه تانوس پذیرفته شد بنیاد رایانش بومی ابر، که شامل Prometheus، Kubernetes و سایر پروژه های محبوب است.

در ژانویه 2018، توسعه VictoriaMetrics آغاز شد.

در سپتامبر 2018، من برای اولین بار به طور عمومی به VictoriaMetrics اشاره کردم.

در دسامبر 2018، یک نسخه تک گره منتشر شد.

در ماه مه 2019 منتشر شدند منابع هر دو نسخه Single-node و Cluster.

در ژوئن 2019، درست مانند تانوس، درخواستی را به بنیاد CNCF با شماره ارسال کردیم 255. ما یک روز قبل از درخواست تانوس درخواست دادیم.

اما متاسفانه هنوز در آنجا پذیرفته نشدیم. کمک جامعه مورد نیاز است.

بیایید به مهم ترین اسلایدهایی که معماری Thanos و VictoriaMetrics را نشان می دهند نگاه کنیم.

بیایید با تانوس شروع کنیم. اجزای زرد از اجزای پرومتئوس هستند. بقیه اجزای Thanos هستند. بیایید با مهمترین مؤلفه شروع کنیم. Thanos Sidecar قطعه ای است که در کنار هر Prometheus نصب می شود. داده های Prometheus را از حافظه محلی در S3 یا یک Object Storage بارگذاری می کند.

همچنین مؤلفه‌ای به نام Thanos Store Gateway وجود دارد که می‌تواند این داده‌ها را از Object Storage در صورت درخواست‌های دریافتی Thanos Query بخواند. Thanos Query PromQL و Prometheus API را پیاده سازی می کند. یعنی از بیرون شبیه پرومتئوس است. درخواست‌های PromQL را دریافت می‌کند، آنها را به Thanos Store Gateway می‌فرستد، Thanos Store Gateway داده‌های لازم را از Object Storage بازیابی می‌کند، آن را پس می‌فرستد.

اما ما داده‌ها را بدون دو ساعت گذشته در Object Storage ذخیره می‌کنیم که دلیل آن یکی از ویژگی‌های پیاده‌سازی Thanos Sidecar است که نمی‌تواند دو ساعت گذشته را در Object Storage S3 آپلود کند، زیرا Prometheus هنوز فایل‌هایی را برای این دو ساعت در حافظه محلی ایجاد نکرده است.

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

و Thanos Sidecar نیز به نوبه خود درخواست های بیشتری را به Prometheus می دهد و داده های دو ساعت گذشته را بازیابی می کند.

علاوه بر این قطعات، یک قطعه اختیاری نیز وجود دارد که بدون آن Thanos عملکرد خوبی نخواهد داشت. این Thanos Compact است که مسئول ادغام فایل‌های کوچک در Object Storage به فایل‌های بزرگ‌تر است که توسط Thanos Sidecars در اینجا آپلود شده‌اند. Thanos Sidecar فایل های داده را در دو ساعت در آنجا آپلود می کند. اگر این فایل‌ها در فایل‌های بزرگ‌تر ادغام نشوند، تعداد آنها می‌تواند بسیار افزایش یابد. هرچه تعداد این فایل ها بیشتر باشد، حافظه بیشتری برای Thanos Store Gateway مورد نیاز است، منابع بیشتری برای انتقال داده ها از طریق شبکه و ابرداده مورد نیاز است. Thanos Store Gateway بی اثر می شود. بنابراین لازم است Thanos Compact را اجرا کنید که فایل‌های کوچک را با فایل‌های بزرگ‌تر ادغام می‌کند تا تعداد کمتری از این فایل‌ها وجود داشته باشد و هزینه‌های اضافی بر روی Thanos Store Gateway کاهش یابد.

همچنین مؤلفه ای به عنوان خط کش Thanos وجود دارد. قوانین هشدار Prometheus را اجرا می کند و می تواند قوانین ضبط Prometheus را برای بازنویسی داده ها به Object Storage ارزیابی کند. اما استفاده از این جزء توصیه نمی شود، زیرا ... او تمایل به بازگشت داده های ناقص دارد.

این طرح ساده تانوس است.

حالا بیایید آن را با طرح VictoriaMetrics مقایسه کنیم.

VictoriaMetrics دارای 2 نسخه است: نسخه تک گره و خوشه ای. Single-node روی یک کامپیوتر اجرا می شود. Single-node این اجزا را ندارد، فقط یک باینری دارد. این باینری در اسلاید شبیه این مربع است. هر چیزی که داخل مربع است محتویات فایل باینری نسخه Single-node است. شما نیازی به دانستن او ندارید. شما فقط باینری را اجرا می کنید و همه چیز برای ما کار می کند.

نسخه خوشه ای پیچیده تر است. در داخل آن سه جزء مختلف وجود دارد: vmselect، vminsert و vmstorage. از نام آنها باید مشخص شود که هر کدام از آنها چه می کنند. مؤلفه Insert داده ها را در قالب های مختلف می پذیرد: از API نوشتن از راه دور Prometheus، پروتکل خط Influx، پروتکل Graphite و پروتکل OpenTSDB. مؤلفه Insert آنها را می پذیرد، آنها را تجزیه می کند و بین اجزای ذخیره سازی موجود، جایی که داده ها قبلاً ذخیره شده اند، توزیع می کند. مؤلفه Select، به نوبه خود، درخواست های PromQL را می پذیرد. اجرا می کند PromQLو همچنین API پرس و جوی Prometheus، و می تواند به عنوان جایگزینی برای Prometheus در Grafana یا سایر مشتریان API Prometheus استفاده شود. Select درخواست promql را می‌پذیرد، آن را تجزیه می‌کند، داده‌های لازم برای اجرای این درخواست را از گره‌های ذخیره‌سازی می‌خواند، این داده‌ها را پردازش می‌کند و پاسخی را برمی‌گرداند.

بیایید پیچیدگی نصب Thanos و VictoriaMetrics را با هم مقایسه کنیم.

بیایید با تانوس شروع کنیم. قبل از شروع کار با Thanos، باید یک سطل در Object Storage مانند S3 یا GCS ایجاد کنید تا Thanos Sidecar بتواند روی آن داده بنویسد.

سپس برای هر Prometheus باید Thanos Sidecar را نصب کنید. قبل از این، باید به یاد داشته باشید که فشرده سازی داده ها را در Prometheus غیرفعال کنید. فشرده سازی داده ها به طور دوره ای داده ها را در ذخیره سازی محلی Prometheus فشرده می کند تا مصرف منابع را کاهش دهد.

وقتی Thanos Sidecar را روی Prometheus خود نصب می کنید، باید این فشرده سازی داده را غیرفعال کنید، زیرا Thanos Sidecar با فعال کردن فشرده سازی داده به درستی کار نمی کند. این بدان معنی است که Prometheus شما شروع به ذخیره داده ها در بلوک های دو ساعته می کند و از ادغام آن بلوک ها به بلوک های بزرگتر جلوگیری می کند. بر این اساس، اگر پرس و جوهایی را بیشتر از مدت زمان دو ساعت گذشته انجام دهید، در صورت فعال بودن فشرده سازی داده ها، به همان اندازه که می توانستند کار کنند کار نمی کنند.

بنابراین، Thanos توصیه می‌کند که زمان نگهداری داده‌ها در ذخیره‌سازی محلی را به 6-8 ساعت کاهش دهید تا سربار تعداد زیادی بلوک کوچک کاهش یابد.

پس از نصب Thanos Sidecar، باید دو کامپوننت برای هر Object Storage Bucket نصب کنید. اینها Thanos Compactor و Thanos Store Gateway هستند.

پس از آن، باید Thanos Query را نصب کرده و آن را پیکربندی کنید تا بتواند به تمام دروازه‌های فروشگاهی Thanos که شما دارید متصل شود و همچنین بتواند به همه Thanos Sidecars متصل شود.

در اینجا ممکن است یک مشکل جزئی وجود داشته باشد.

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

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

در VictoriaMetrics همه چیز کمی ساده تر است. برای نسخه Single-node، فقط باید یک باینری اجرا کنید و همه چیز کار می کند.

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

پس از راه‌اندازی یک نسخه باینری یا خوشه‌ای، فقط باید Prometheus را به پیکربندی اضافه کنید. تنظیم آدرس اینترنتی نوشتن از راه دوربه طوری که شروع به نوشتن داده ها به موازات ذخیره سازی محلی و ذخیره سازی از راه دور می کند. همانطور که می بینید، این پیکربندی در مقایسه با پیکربندی Thanos باید بسیار قابل اعتمادتر عمل کند. ما نیازی به حفظ اتصال از VictoriaMetrics به تمام Prometheus نداریم، زیرا Prometheus خود به VictoriaMetrics متصل شده و داده ها را انتقال می دهد.

بیایید پشتیبانی Thanos و VictoriaMetrics را در نظر بگیریم.

Thanos باید Sidecar را نظارت کند تا مطمئن شود که بارگذاری داده‌ها در Object Storage را متوقف نمی‌کند. آنها ممکن است این دانلود داده را به دلیل خطاهای دانلود متوقف کنند، برای مثال اتصال شبکه شما به Object Storage موقتاً قطع شده است یا Object Storage موقتاً در دسترس نیست. Thanos Sidecar در این لحظه متوجه این موضوع می شود، خطا را گزارش می دهد، ممکن است خراب شود و سپس کار را متوقف کند. اگر آن را نظارت نکنید، انتقال داده به Object Storage را متوقف خواهید کرد. اگر زمان نگهداری بگذرد (6 تا 8 ساعت توصیه می شود)، داده هایی را که به Object Storage ختم نشده اند از دست خواهید داد.

کمپکتورهای ثانوس ممکن است به دلیل مسابقه با Sidecar است. فشرده‌کننده‌ها داده‌ها را از Object Storage می‌گیرند و آن‌ها را در قطعات بزرگ‌تری از داده‌ها ادغام می‌کنند. از آنجایی که فشرده‌کننده‌ها با Sidecars همگام نیستند، موارد زیر ممکن است اتفاق بیفتد: Sidecar هنوز زمان لازم برای تکمیل بلوک را نداشته است، Compactor تصمیم می‌گیرد که این بلوک کاملاً نوشته شده است. کمپکتور شروع به خواندن آن می کند. بلوک را به طور کامل نمی خواند و کار نمی کند. جزییات را ببینید اینجا.

Store Gateway ممکن است داده های متناقض را به دلیل رقابت بین Compactor و Sidecars برگرداند. در اینجا هم همین اتفاق می افتد، زیرا دروازه فروشگاه به هیچ وجه با Compactors و Sidecars همگام نیست. بر این اساس، شرایط مسابقه زمانی رخ می دهد که دروازه فروشگاه بخشی از داده ها را نمی بیند یا داده های غیر ضروری را می بیند.

اگر برخی از Sidecars یا Store Gateways در حال حاضر در دسترس نباشند، جزء Query در Thanos به طور پیش‌فرض یک نتیجه جزئی را برمی‌گرداند. شما بخشی از داده ها را دریافت خواهید کرد و حتی نمی دانید که همه داده ها را دریافت نکرده اید. به صورت پیش فرض اینگونه کار می کند. در وضعیت مشابه، VictoriaMetrics داده های علامت گذاری شده را به عنوان جزئی برمی گرداند.

برخلاف Thanos، VictoriaMetrics به ندرت داده ها را از دست می دهد. حتی اگر اتصال Prometheus به VictoriaMetrics قطع شود، این مشکلی نیست، زیرا Prometheus همچنان به ثبت داده های جدید دریافتی در Write Ahead Log که اندازه آن 2 ساعت است، ادامه می دهد. اگر ظرف دو ساعت اتصال خود را به VictoriaMetrics بازیابی کنید، داده های شما از بین نمی رود. پرومتئوس می تواند پس از بازیابی اتصال به VictoriaMetrics داده ها را اضافه کند.

برخلاف Thanos که داده‌ها را تنها پس از دو ساعت در ذخیره‌سازی اشیاء می‌نویسد، Prometheus به طور خودکار داده‌ها را با استفاده از پروتکل نوشتن از راه دور برای ذخیره‌سازی از راه دور مانند VictoriaMetrics تکرار می‌کند. شما از از دست دادن فضای ذخیره سازی محلی در Prometheus نمی ترسید. اگر او به طور ناگهانی فضای ذخیره سازی محلی را از دست داد، در بدترین حالت، آخرین ثانیه از داده هایی را که زمان برای ثبت در ذخیره سازی از راه دور نداشتند، از دست خواهید داد.

Kubernetes به طور خودکار خوشه را بر خلاف Thanos مدیریت می کند. بر خلاف مولفه های خوشه VictoriaMetrics، قرار دادن تمام اجزای Thanos در یک خوشه Kubernetes دشوار است.

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

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

درباره مشکلات در Thanos و VictoriaMetrics.

Thanos دارای مشکلات زیر است. پرومتئوس باید داده ها را برای دو ساعت گذشته ذخیره کند. اگر آنها گم شوند، شما آنها را به طور کامل از دست خواهید داد زیرا هنوز مانند S3 در Object Storage نوشته نشده اند.

کامپوننت Store Gateway و Compactor می تواند برای کار با یک Object Storage بزرگ به حافظه زیادی نیاز داشته باشد، اگر فایل های کوچک زیادی در آنجا ذخیره شده باشد. هرچه تعداد و اندازه فایل ها بیشتر باشد، برای ذخیره اطلاعات فرا اطلاعاتی به Store Gateway و رم فشرده کننده بیشتری نیاز است. تانوس در مورد این واقعیت مشکلات زیادی دارد خرابی دروازه فروشگاه و فشرده ساز با حجم متوسط ​​داده های ثبت شده.

ثانوس به اندازه نامحدود با مقدار پرومتئوس شما تبلیغ می شود. این در واقع درست نیست. از آنجایی که همه درخواست‌ها از طریق کامپوننت Query انجام می‌شوند، که باید به طور همزمان همه اجزای Store Gateway و همه اجزای Sidecar را بررسی کند، داده‌ها را از آنجا بیرون بکشید و سپس آن را از قبل پردازش کنید. بدیهی است که سرعت درخواست توسط کندترین لینک ضعیف، کندترین دروازه فروشگاه یا کندترین Sidecar محدود می شود.

این اجزا ممکن است به طور ناهموار بارگذاری شوند. به عنوان مثال، شما Prometheus را دارید که میلیون ها متریک در ثانیه جمع آوری می کند. و پرومتئوس وجود دارد که هزاران متریک در ثانیه جمع آوری می کند. پرومتئوس، که میلیون ها معیار در ثانیه جمع آوری می کند، بار بسیار بیشتری را روی سروری که روی آن اجرا می شود، وارد می کند. بر این اساس، Sidecar در آنجا کندتر کار می کند. و به طور کلی همه چیز در آنجا به کندی کار می کند. و کامپوننت Query داده‌ها را به آرامی از آنجا بیرون می‌کشد. بر این اساس، عملکرد کل خوشه شما توسط این Sidecar کند محدود می شود.

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

VictoriaMetrics همچنین دارای مشکلاتی است. اولین دام گزینه ای است که مقدار RAM مورد استفاده برای کش VictoriaMetrics را محدود می کند. به‌طور پیش‌فرض، برابر با 60 درصد رم دستگاهی است که VictoriaMetrics در آن کار می‌کند یا 60 درصد RAM پاد VictoriaMetrics در Kubernetes.

اگر این مقدار را به اشتباه تغییر دهید، می توانید عملکرد VictoriaMetrics را خراب کنید. برای مثال، اگر مقدار را خیلی پایین تنظیم کنید، ممکن است داده‌ها دیگر در حافظه پنهان VictoriaMetrics قرار نگیرند. به همین دلیل، او باید کارهای اضافی انجام دهد و پردازنده و دیسک را بارگذاری کند. اگر این گزینه را خیلی بزرگ کنید، اولاً احتمال خراب شدن VictoriaMetrics با خطای کمبود حافظه را افزایش می دهد و ثانیاً منجر به این واقعیت می شود که RAM بسیار کمی در حافظه سیستم عامل باقی خواهد ماند. کش فایل و VictoriaMetrics برای عملکرد به کش فایل متکی است. اگر کافی نباشد، بار روی دیسک می تواند تا حد زیادی افزایش یابد. بنابراین، توصیه: پارامتر را تغییر ندهید مگر اینکه کاملاً ضروری باشد.

گزینه دوم. این RetentionPeriod است - دوره ای که به طور پیش فرض روی 1 ماه تنظیم شده است. این مدت زمانی است که VictoriaMetrics داده ها را ذخیره می کند. پس از این مدت، VictoriaMetrics داده ها را حذف می کند.

بسیاری از افراد VictoriaMetrics را بدون این پارامتر اجرا می کنند و داده ها را برای یک ماه ضبط می کنند. و سپس می پرسند: چرا داده های ماه قبل ناپدید شد؟ زیرا RetentionPeriod پیش فرض 1 ماه است. بنابراین، شما باید زمان نگهداری صحیح را بدانید و تنظیم کنید.

بیایید نگاهی به ویژگی های منحصر به فرد بیندازیم.

Thanos یک ویژگی به نام نمونه برداری پایین دارد: فواصل 5 دقیقه ای و ساعتی، که اغلب درست کار نمی کند. اگر در گوگل سرچ کنید و به مشکل آنها در github نگاه کنید، مشکلات زیادی در رابطه با این نمونه برداری وجود دارد که گاهی اوقات به درستی کار نمی کند یا آنطور که کاربران انتظار دارند کار نمی کند.

Thanos برای جفت‌های Prometheus HA، داده‌های کپی‌برداری دارد. زمانی که دو پرومتئوس معیارهای یکسانی را از اهداف مشابه جمع آوری می کنند و تانوس آنها را در Object Storage ذخیره می کند. Thanos برخلاف VictoriaMetrics می‌تواند این داده‌ها را به درستی کپی کند.

Thanos دارای یک جزء هشدار است که در شماتیک Thanos وجود داشت. اما او برای استفاده در تولید توصیه نمی شود.

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

ویژگی اصلی VictoriaMetrics MetricsQL است. اینها افزونه های VictoriaMetrics برای PromQL هستند که در جلسه نظارت بزرگ قبلی در مورد آنها صحبت کردم.

VictoriaMetrics از بارگیری داده ها با استفاده از پروتکل های مختلف پشتیبانی می کند. VictoriaMetrics نه تنها می‌تواند داده‌های Prometheus را بپذیرد، بلکه می‌تواند از طریق پروتکل‌های Influx، OpenTSDB و Graphite نیز بپذیرد.

داده های VictoriaMetrics در مقایسه با Thanos و Prometheus فضای بسیار کمتری را اشغال می کند.

اگر داده های واقعی را ضبط کنید، کاربران در مورد کاهش 2-5 برابری اندازه داده ها روی دیسک در مقایسه با Prometheus و Thanos صحبت می کنند.

یکی دیگر از مزایای VictoriaMetrics این است که برای سرعت بهینه شده است.

بیایید به هزینه زیرساخت ها نگاه کنیم.

یکی از مزایای Thanos این است که داده ها را در ذخیره سازی اشیاء ذخیره می کند که نسبتاً ارزان است.

هنگام ذخیره داده ها در ذخیره سازی اشیاء، باید برای عملیات نوشتن و خواندن داده ها بپردازید (10 دلار به ازای هر میلیون عملیات). وقتی داده‌ها را در ذخیره‌سازی شی می‌نویسید، هزینه‌های میزبانی خود را برای آپلود داده‌ها در اینترنت می‌پردازید؛ اگر خوشه شما در AWS نباشد، در آنجا رایگان است. وقتی داده ها را می خوانید، بین 10 تا 230 دلار به ازای هر 1 ترابایت پرداخت می کنید. اگر به طور مکرر داده های تاریخی را از خوشه Thanos جستجو کنید، می تواند مهم باشد.

برای یک کلاستر Thanos، شما باید برای سرورهای Compact، Store Gateway، اجزای Query که به حافظه زیادی نیاز دارند و CPU برای حجم زیادی از داده ها هزینه کنید.

VictoriaMetrics دارای هزینه های زیر است. اگر داده‌ها را روی درایوهای GCE HDD ذخیره می‌کنید، برای 40 ترابایت به 1 دلار می‌رسد. برای VictoriaMetrics، درایوهای HDD معمولی کافی هستند؛ هیچ SSD، که پنج برابر قیمت بیشتری دارد، مورد نیاز نیست. VictoriaMetrics برای HDD بهینه شده است.

VictoriaMetrics برای کامپوننت‌ها به سرور نیاز دارد: اجزای Single-nod یا Clustered که برخلاف اجزای Thanos، به CPU و RAM بسیار کمتری نیاز دارند - و بر این اساس ارزان‌تر خواهند بود.

نمونه هایی از اجرا

Thanos یک نمونه پیاده سازی در Gitlab دارد. Gitlab به طور کامل بر روی Thanos اجرا می شود. اما در آنجا همه چیز آنقدر هموار نیست. اگر به آنها نگاه کنید مسائل، سپس می توانید ببینید که آنها دائماً مقداری دارند مشکلات عملیاتی با Thanos: حافظه کافی برای اجزای Store Gateway یا Query وجود ندارد. آنها مدام باید میزان حافظه را افزایش دهند.

به همین دلیل هزینه های حل این مشکلات افزایش می یابد.

دومین پیاده سازی که ممکن است موفقیت آمیزتر باشد، شرکت Improbable است که توسعه Thanos را آغاز کرد. آنها کد منبع Thanos را منتشر کردند. Improbable شرکتی است که موتورهای بازی را توسعه می دهد.

VictoriaMetrics نمونه های اجرای عمومی دارد:

• سازنده وب سایت wix.com
• آدیداس در حال پیاده سازی VictoriaMetrics است و حتی در آخرین PromCon 2019 ارائه کرده است.
• TrafficStars - شبکه تبلیغات
• Seznam.cz یک موتور جستجوی محبوب چک است.

و پس از آن شرکت‌های بی‌نامی وجود داشتند که اکنون نمی‌توانم آنها را نام ببرم. رضایت ندادند.

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

نتیجه گیری

VictoriaMetrics و Thanos مشکلات مشابه را حل می کنند، اما به روش های مختلف:

• نمای کلی پرس و جو
• مقیاس بندی افقی
• نگهداری خودسرانه

متشکرم.

در محل ما منتظر شما هستیم کانال تلگرام.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

از چه چیزی به عنوان ذخیره سازی طولانی مدت برای Prometheus استفاده می کنید؟

• ٪۱۰۰Thanos6

• ٪۱۰۰Cortex0

• ٪۱۰۰M3DB0

• ٪۱۰۰VictoriaMetrics7

• ٪۱۰۰دیگر4

17 کاربر رای دادند. 16 کاربر رای ممتنع دادند.

منبع: www.habr.com