تانوس - پرومتئوس مقیاس پذیر

ترجمه مقاله به طور اختصاصی برای دانشجویان دوره تهیه شده است "روش ها و ابزارهای DevOps".

فابیان رینارتز یک توسعه دهنده نرم افزار، متعصب Go و حل کننده مشکلات است. او همچنین نگهدارنده Prometheus و یکی از بنیانگذاران ابزار دقیق Kubernetes SIG است. در گذشته، او یک مهندس تولید در SoundCloud بود و تیم نظارت در CoreOS را رهبری می کرد. در حال حاضر در گوگل کار می کند.

بارتک پلوتکا - مهندس زیرساخت در Improbable. او به فن آوری های جدید و مشکلات سیستم های توزیع شده علاقه مند است. او دارای تجربه برنامه نویسی سطح پایین در اینتل، تجربه مشارکت کننده در Mesos و تجربه تولید SRE در سطح جهانی در Improbable است. اختصاص به بهبود دنیای میکروسرویس ها. سه عشق او: گولنگ، متن باز و والیبال.

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

سادگی و قابلیت اطمینان پرومتئوس یکی از مزایای اصلی آن است. با این حال، هنگامی که از یک مقیاس خاص عبور کردیم، با چندین اشکال مواجه شدیم. برای حل این مشکلات ما توسعه داده ایم Thanos یک پروژه منبع باز است که توسط Improbable برای تبدیل یکپارچه خوشه های Prometheus موجود به یک سیستم نظارتی واحد با ذخیره سازی نامحدود داده های تاریخی ایجاد شده است. Thanos در Github در دسترس است اینجا.

با آخرین اخبار از Improbable به روز باشید.

اهداف ما با تانوس

در مقیاسی خاص، مشکلاتی به وجود می آید که فراتر از توانایی های پرومته وانیلی است. چگونه می توان پتابایت داده های تاریخی را به طور قابل اعتماد و اقتصادی ذخیره کرد؟ آیا می توان این کار را بدون به خطر انداختن زمان پاسخ انجام داد؟ آیا با یک درخواست API امکان دسترسی به تمام معیارهای موجود در سرورهای مختلف Prometheus وجود دارد؟ آیا راهی برای ترکیب داده های تکراری جمع آوری شده با استفاده از Prometheus HA وجود دارد؟

برای رسیدگی به این مسائل، ما Thanos را ایجاد کردیم. بخش های بعدی نحوه برخورد ما با این مسائل را توضیح می دهد و اهداف خود را توضیح می دهد.

جست و جوی داده ها از چندین نمونه پرومتئوس (پرس و جوی جهانی)

Prometheus یک رویکرد کاربردی برای شاردینگ ارائه می دهد. حتی یک سرور Prometheus مقیاس پذیری کافی را برای رهایی کاربران از پیچیدگی های تقسیم افقی تقریباً در همه موارد استفاده فراهم می کند.

در حالی که این یک مدل استقرار عالی است، اغلب لازم است به داده‌های سرورهای مختلف Prometheus از طریق یک API یا UI واحد دسترسی داشته باشید - یک نمای جهانی. البته امکان نمایش چند پرس و جو در یک پنل گرافانا وجود دارد، اما هر کوئری فقط در یک سرور Prometheus قابل اجرا است. از سوی دیگر، با Thanos می‌توانید داده‌ها را از چندین سرور Prometheus جست‌وجو و جمع‌آوری کنید، زیرا همه آنها از یک نقطه پایانی در دسترس هستند.

قبلاً، برای به دست آوردن یک نمای جهانی در Improbable، نمونه‌های Prometheus خود را در چند سطح سازماندهی کردیم. فدراسیون سلسله مراتبی. این به معنای ایجاد یک متا سرور Prometheus است که برخی از معیارها را از هر سرور برگ جمع‌آوری می‌کند.

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

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

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

ذخیره سازی قابل اعتماد داده های تاریخی

ذخیره سازی معیارهای ارزان، سریع و طولانی مدت رویای ماست (که توسط اکثر کاربران Prometheus مشترک است). در Improbable، ما مجبور شدیم دوره نگهداری معیارها را به 1.8 روز (برای Prometheus XNUMX) پیکربندی کنیم. این محدودیت های آشکاری را برای اینکه چقدر می توانیم به عقب نگاه کنیم اضافه می کند.

Prometheus 2.0 در این زمینه بهبود یافته است، زیرا تعداد سری های زمانی دیگر بر عملکرد کلی سرور تأثیر نمی گذارد (نگاه کنید به. سخنرانی اصلی KubeCon درباره Prometheus 2). با این حال، Prometheus داده ها را روی دیسک محلی ذخیره می کند. اگرچه فشرده‌سازی داده‌های با راندمان بالا می‌تواند استفاده محلی SSD را به میزان قابل توجهی کاهش دهد، اما در نهایت هنوز محدودیتی برای مقدار داده‌های تاریخی قابل ذخیره‌سازی وجود دارد.

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

کاهش نمونه

هنگامی که کار با داده های تاریخی را شروع کردیم، متوجه شدیم که مشکلات اساسی با big-O وجود دارد که با کار با داده های هفته ها، ماه ها و سال ها، درخواست ها را کندتر و کندتر می کند.

راه حل استاندارد برای این مشکل خواهد بود پایین نمونه گیری (downsampling) - کاهش فرکانس نمونه برداری سیگنال. با پایین‌نمونه‌سازی، می‌توانیم «کاهش» را به محدوده زمانی بزرگ‌تری کاهش دهیم و همان تعداد نمونه را حفظ کنیم و پرسش‌ها را پاسخگو نگه داریم.

نمونه برداری از داده های قدیمی یک نیاز اجتناب ناپذیر برای هر راه حل ذخیره سازی طولانی مدت است و فراتر از محدوده Prometheus وانیلی است.

اهداف اضافی

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

معماری ثانوس

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

نمای جهانی

برای به دست آوردن یک نمای کلی در بالای نمونه های موجود Prometheus، باید یک نقطه ورود درخواست را به همه سرورها پیوند دهیم. این دقیقاً همان کاری است که مؤلفه Thanos انجام می دهد. Sidecar. در کنار هر سرور Prometheus مستقر می شود و به عنوان یک پروکسی عمل می کند و داده های محلی Prometheus را از طریق gRPC Store API ارائه می دهد و به داده های سری زمانی اجازه می دهد تا توسط برچسب و محدوده زمانی بازیابی شوند.

در طرف دیگر، مؤلفه Querier بدون حالت است که چیزی بیشتر از پاسخ دادن به سؤالات PromQL از طریق API استاندارد Prometheus HTTP انجام نمی دهد. Querier، Sidecar و سایر اجزای Thanos از طریق ارتباط برقرار می کنند پروتکل شایعات.

1. Querier پس از دریافت درخواست، به سرور مربوطه Store API، یعنی به Sidecars ما متصل می شود و داده های سری زمانی را از سرورهای Prometheus مربوطه دریافت می کند.
2. پس از آن، پاسخ ها را ترکیب می کند و یک پرس و جو PromQL را روی آنها اجرا می کند. Querier می‌تواند داده‌های مجزا و داده‌های تکراری را از سرورهای Prometheus HA ادغام کند.

این بخش عمده ای از پازل ما را حل می کند - ترکیب داده های سرورهای Prometheus ایزوله در یک نمای واحد. در واقع Thanos فقط برای این ویژگی قابل استفاده است. نیازی به تغییر در سرورهای موجود Prometheus نیست!

ماندگاری نامحدود!

با این حال، دیر یا زود می خواهیم داده ها را فراتر از زمان نگهداری معمولی Prometheus ذخیره کنیم. ما ذخیره‌سازی شی را برای ذخیره داده‌های تاریخی انتخاب کردیم. این به طور گسترده در هر ابری و همچنین مراکز داده داخلی در دسترس است و بسیار مقرون به صرفه است. علاوه بر این، تقریباً هر ذخیره سازی شی از طریق API معروف S3 در دسترس است.

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

بارگیری در فضای ذخیره سازی شی بلافاصله پس از نوشتن روی دیسک همچنین به شما امکان می دهد تا سادگی اسکراپر را حفظ کنید (Prometheus و Thanos Sidecar). که پشتیبانی، هزینه و طراحی سیستم را ساده می کند.

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

جزء Thanos Store به عنوان یک پروکسی برای بازیابی داده ها از ذخیره سازی اشیا عمل می کند. مانند Thanos Sidecar، در خوشه شایعات شرکت می کند و API فروشگاه را پیاده سازی می کند. به این ترتیب، Querier موجود می تواند با آن مانند یک Sidecar، به عنوان منبع دیگری از داده های سری زمانی رفتار کند - بدون نیاز به پیکربندی خاصی.

بلوک های داده سری زمانی از چندین فایل بزرگ تشکیل شده است. بارگیری آنها بر اساس تقاضا کاملاً ناکارآمد خواهد بود و ذخیره آنها به صورت محلی به مقدار زیادی حافظه و فضای دیسک نیاز دارد.

در عوض، Store Gateway می داند که چگونه با فرمت ذخیره سازی Prometheus کار کند. به لطف یک زمان‌بندی پرس و جو هوشمند و ذخیره تنها بخش‌های فهرست ضروری بلوک‌ها، می‌توان پرس‌و‌جوهای پیچیده را به حداقل تعداد درخواست‌های HTTP برای شی فایل‌های ذخیره‌سازی کاهش داد. به این ترتیب، می‌توانید تعداد درخواست‌ها را چهار تا شش مرتبه کاهش دهید و به زمان‌های پاسخی دست یابید که تشخیص آن‌ها از درخواست‌ها به داده‌ها در یک SSD محلی معمولاً دشوار است.

همانطور که در نمودار بالا نشان داده شده است، Thanos Querier با استفاده از فرمت ذخیره سازی Prometheus و قرار دادن داده های مرتبط در کنار هم، به طور قابل توجهی هزینه هر پرس و جو داده های ذخیره سازی اشیاء را کاهش می دهد. با استفاده از این رویکرد، می‌توانیم بسیاری از درخواست‌های منفرد را در حداقل تعداد عملیات انبوه ترکیب کنیم.

فشرده سازی و نمونه برداری پایین

هنگامی که یک بلوک جدید از داده های سری زمانی با موفقیت در ذخیره سازی اشیاء بارگذاری شد، آن را به عنوان داده های "تاریخی" در نظر می گیریم که بلافاصله از طریق دروازه فروشگاه در دسترس است.

با این حال، پس از مدتی، بلوک های یک منبع (Prometheus با Sidecar) جمع می شوند و دیگر از پتانسیل نمایه سازی کامل استفاده نمی کنند. برای حل این مشکل کامپوننت دیگری به نام Compactor را معرفی کردیم. این به سادگی موتور فشرده سازی محلی Prometheus را برای داده های تاریخی در ذخیره سازی اشیاء اعمال می کند و می تواند به عنوان یک کار دسته ای دوره ای ساده اجرا شود.

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

برای نمونه برداری از داده ها، Compactor به طور مداوم داده ها را با وضوح پنج دقیقه و یک ساعت جمع می کند. برای هر قطعه خام که با استفاده از فشرده‌سازی TSDB XOR کدگذاری می‌شود، انواع مختلفی از داده‌های انبوه ذخیره می‌شوند، مانند حداقل، حداکثر یا مجموع برای یک بلوک. این به Querier اجازه می‌دهد تا به طور خودکار مجموعه‌ای را انتخاب کند که برای یک پرس و جوی خاص PromQL مناسب است.

هیچ پیکربندی خاصی برای استفاده کاربر از داده های با دقت کمتر مورد نیاز نیست. Querier به‌طور خودکار بین وضوح‌های مختلف و داده‌های خام سوئیچ می‌کند که کاربر بزرگ‌نمایی و کوچک‌نمایی می‌کند. در صورت تمایل، کاربر می تواند این را مستقیماً از طریق پارامتر "step" در درخواست کنترل کند.

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

قوانین ضبط

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

• هشدار و قانون جهانی (به عنوان مثال، هشدار زمانی که یک سرویس در بیش از دو تا از سه خوشه کار نمی کند).
• قانون برای داده های خارج از ذخیره سازی محلی.
• تمایل به ذخیره همه قوانین و هشدارها در یک مکان.

برای همه این موارد، Thanos شامل یک جزء مجزا به نام Ruler است که قانون و هشدار را از طریق Thanos Queries محاسبه می‌کند. با ارائه یک StoreAPI معروف، گره Query می تواند به معیارهای تازه محاسبه شده دسترسی داشته باشد. بعداً آنها نیز در ذخیره سازی اشیاء ذخیره می شوند و از طریق Store Gateway در دسترس قرار می گیرند.

قدرت ثانوس

Thanos به اندازه کافی انعطاف پذیر است تا مطابق با نیازهای شما سفارشی شود. این به ویژه هنگام مهاجرت از پرومتئوس ساده مفید است. بیایید به سرعت آنچه را که در مورد اجزای Thanos آموخته ایم را با یک مثال سریع مرور کنیم. در اینجا نحوه بردن Prometheus وانیلی خود به دنیای "ذخیره سازی نامحدود معیارها" آورده شده است:

1. Thanos Sidecar را به سرورهای Prometheus خود اضافه کنید - به عنوان مثال، یک ظرف کناری در یک غلاف Kubernetes.
2. چندین نسخه تکراری Thanos Querier را برای مشاهده داده ها مستقر کنید. در این مرحله ایجاد شایعات بین Scraper و Querier آسان است. برای بررسی تعامل مؤلفه‌ها، از متریک «thanos_cluster_members» استفاده کنید.

فقط این دو مرحله برای ارائه نمای جهانی و حذف یکپارچه داده ها از کپی های بالقوه Prometheus HA کافی است! به سادگی داشبوردهای خود را به نقطه پایانی Querier HTTP متصل کنید یا مستقیماً از Thanos UI استفاده کنید.

با این حال، اگر به پشتیبان گیری معیارها و ذخیره سازی طولانی مدت نیاز دارید، باید سه مرحله دیگر را تکمیل کنید:

1. یک سطل AWS S3 یا GCS ایجاد کنید. Sidecar را برای کپی کردن داده ها در این سطل ها پیکربندی کنید. اکنون می توان ذخیره سازی داده های محلی را به حداقل رساند.
2. دروازه فروشگاه را مستقر کرده و آن را به خوشه شایعات موجود خود متصل کنید. اکنون می توانید از داده های پشتیبان گیری شده پرس و جو کنید!
3. برای بهبود کارایی پرس و جو در مدت زمان طولانی با استفاده از فشرده سازی و نمونه برداری کوچک، Compactor را مستقر کنید.

اگر می خواهید بیشتر بدانید، دریغ نکنید به ما نگاه کنید نمونه های آشکار kubernetes и شروع شدن!

تنها در پنج مرحله، ما Prometheus را به یک سیستم نظارت قابل اعتماد با نمای جهانی، زمان ذخیره سازی نامحدود و در دسترس بودن بالقوه بالای معیارها تبدیل کردیم.

درخواست کشش: ما به شما نیاز داریم!

Thanos از همان ابتدا یک پروژه متن باز بوده است. ادغام یکپارچه با Prometheus و توانایی استفاده از تنها بخشی از Thanos، آن را به انتخابی عالی برای مقیاس‌بندی بدون زحمت سیستم مانیتورینگ تبدیل می‌کند.

ما همیشه از درخواست ها و مشکلات GitHub Pull استقبال می کنیم. در ضمن، از طریق Github Issues یا Slack با ما تماس بگیرید نامحتمل-eng #thanosاگر سوال یا بازخوردی دارید، یا می خواهید تجربه خود را در استفاده از آن به اشتراک بگذارید! اگر کاری که ما در Improbable انجام می دهیم را دوست دارید، دریغ نکنید با ما تماس بگیرید - ما همیشه جای خالی داریم!

درباره دوره بیشتر بدانید.

منبع: www.habr.com