نظارت بر خوشه Kubernetes: بررسی اجمالی و مقدمه ای بر پرومتئوس

بیایید به مفهوم نظارت Kubernetes نگاه کنیم، با ابزار Prometheus آشنا شویم و در مورد هشدار صحبت کنیم.

موضوع نظارت پرحجم است و در یک مقاله نمی توان به آن پرداخت. هدف از این متن ارائه مروری بر ابزارها، مفاهیم و رویکردهاست.

مواد مقاله فشرده از سخنرانی باز مدرسه "اسلرم". اگر می خواهید آموزش کاملی دریافت کنید، برای یک دوره ثبت نام کنید زیرساخت نظارت و ثبت در Kubernetes.

آنچه در یک خوشه Kubernetes نظارت می شود

سرورهای فیزیکی اگر یک خوشه Kubernetes بر روی سرورهای خود مستقر است، باید سلامت آنها را کنترل کنید. Zabbix این وظیفه را بر عهده دارد. اگر با او کار کنید، دیگر نیازی به امتناع نیست، هیچ درگیری وجود نخواهد داشت. این Zabbix است که وضعیت سرورهای ما را نظارت می کند.

بیایید به نظارت در سطح خوشه برویم.

اجزای هواپیمای کنترل: API، Scheduler و دیگران. حداقل باید نظارت داشته باشید که API یا etcd سرور بزرگتر از 0 باشد.

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

DNS اگر DNS در یک خوشه خراب شود، کل سرویس Discovery نیز از کار خواهد افتاد و تماس‌ها از پادها به پادها کار نمی‌کنند. در عمل من، چنین مشکلاتی وجود نداشت، اما این بدان معنا نیست که وضعیت DNS نیازی به نظارت ندارد. تأخیر درخواست و برخی معیارهای دیگر را می توان در CoreDNS ردیابی کرد.

ورود. کنترل در دسترس بودن ورودی ها (از جمله Ingress Controller) به عنوان نقاط ورود به پروژه ضروری است.

اجزای اصلی خوشه جدا شده اند - حالا بیایید پایین تر برویم، به سطح انتزاعات.

به نظر می رسد که برنامه ها در پادها اجرا می شوند، به این معنی که باید کنترل شوند، اما در واقعیت اینطور نیست. پادها زودگذر هستند: امروز روی یک سرور کار می کنند، فردا روی سرور دیگری. امروز 10 تا، فردا 2 تا. در معماری میکروسرویس، کنترل در دسترس بودن برنامه به عنوان یک کل مهمتر است. به ویژه، در دسترس بودن نقاط پایانی سرویس را بررسی کنید: آیا چیزی کار می کند؟ اگر برنامه در دسترس است، پس پشت آن چه اتفاقی می افتد، اکنون چند نسخه وجود دارد - اینها سؤالات مرتبه دوم هستند. نیازی به نظارت بر موارد فردی نیست.

در آخرین سطح، شما باید بر عملکرد خود برنامه نظارت داشته باشید، معیارهای تجاری را در نظر بگیرید: تعداد سفارشات، رفتار کاربر و غیره.

تیتان فرزند پاپتوس

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

چند گزینه برای شروع کار با Prometheus وجود دارد: با استفاده از Helm، می توانید Prometheus معمولی یا Prometheus Operator را نصب کنید.

1. پرومتئوس معمولی همه چیز با آن خوب است، اما شما باید ConfigMap را پیکربندی کنید - اساساً، مانند قبل از معماری میکروسرویس، فایل های پیکربندی متن را بنویسید.
2. Prometheus Operator کمی گسترده تر است، از نظر منطق داخلی کمی پیچیده تر است، اما کار با آن آسان تر است: اشیاء جداگانه وجود دارد، انتزاع ها به خوشه اضافه می شوند، بنابراین کنترل و پیکربندی آنها بسیار راحت تر است.

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

Prometheus به خوبی با Kubernetes یکپارچه شده است: می تواند به سرور API دسترسی داشته باشد و با آن تعامل داشته باشد.

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

معماری پرومتئوس

سرور پرومتئوس - این بخش سرور، مغز پرومتئوس است. این جایی است که معیارها ذخیره و پردازش می شوند.

معیارها در پایگاه داده سری زمانی (TSDB) ذخیره می شوند. TSDB یک پایگاه داده جداگانه نیست، بلکه یک بسته Go است که در Prometheus ساخته شده است. به طور کلی، همه چیز در یک باینری است.

داده ها را برای مدت طولانی در TSDB ذخیره نکنید

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

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

سرور پرومتئوس طبق مدل کار می کند کشیدن: خودش به سراغ متریک ها می رود تا نقاط پایانی که به او داده ایم. آنها گفتند: "به سرور API بروید" و هر nامین ثانیه به آنجا می رود و معیارها را می گیرد.

برای اشیایی با طول عمر کوتاه (job یا cron job) که ممکن است بین دوره های خراشیدن ظاهر شوند، یک جزء Pushgateway وجود دارد. معیارهای مربوط به اشیاء کوتاه‌مدت وارد آن می‌شوند: کار افزایش یافت، عمل کامل شد، معیارها به Pushgateway ارسال شد و تکمیل شد. پس از مدتی، Prometheus با سرعت خود پیش می رود و این معیارها را از Pushgateway می گیرد.

برای پیکربندی اعلان ها در Prometheus یک جزء جداگانه وجود دارد - مدیر هشدار. و قوانین هشدار به عنوان مثال، اگر API سرور 0 باشد، باید یک هشدار ایجاد کنید. هنگامی که رویداد راه اندازی می شود، هشدار برای ارسال بیشتر به مدیر هشدار ارسال می شود. مدیر هشدار تنظیمات مسیریابی کاملاً انعطاف‌پذیری دارد: یک گروه از هشدارها را می‌توان به چت تلگرام ادمین‌ها، گروهی دیگر به چت توسعه‌دهندگان و سومی به چت کارگران زیرساخت ارسال کرد. اعلان ها را می توان به اسلک، تلگرام، ایمیل و کانال های دیگر ارسال کرد.

و در نهایت، من در مورد ویژگی قاتل پرومتئوس به شما خواهم گفت - کشف. هنگام کار با Prometheus، نیازی به تعیین آدرس خاصی از اشیا برای نظارت ندارید، کافی است نوع آنها را مشخص کنید. یعنی نیازی به نوشتن "اینجا آدرس IP است، اینجا پورت - مانیتور" است، در عوض باید تعیین کنید که با چه اصولی این اشیاء را پیدا کنید (اهداف - اهداف). خود پرومتئوس بسته به اینکه کدام اجسام در حال حاضر فعال هستند، موارد ضروری را بالا می کشد و آنها را به نظارت اضافه می کند.

این رویکرد به خوبی با ساختار Kubernetes مطابقت دارد، جایی که همه چیز شناور است: امروز 10 سرور وجود دارد، فردا 3. برای اینکه آدرس IP سرور را هر بار نشان ندهیم، یک بار نوشتیم که چگونه آن را پیدا کنیم - و Discovering این کار را انجام خواهد داد.

زبان پرومتئوس نامیده می شود PromQL. با استفاده از این زبان می توانید مقادیر معیارهای خاصی را بدست آورید و سپس آنها را تبدیل کنید و بر اساس آنها محاسبات تحلیلی بسازید.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

رابط وب پرومتئوس

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

شما می توانید یک پرس و جو در PromQL در خط Expression بنویسید.

تب Alerts حاوی قوانین هشدار است و آنها سه وضعیت دارند:

1. غیر فعال - اگر هشدار در حال حاضر فعال نباشد، یعنی همه چیز با آن خوب است و کار نکرد.
2. در انتظار - این در صورتی است که هشدار فعال شده باشد، اما ارسال هنوز انجام نشده باشد. تأخیر برای جبران چشمک زدن شبکه تنظیم شده است: اگر سرویس مشخص شده در عرض یک دقیقه افزایش یابد، دیگر نیازی به به صدا درآوردن زنگ نیست.
3. شلیک وضعیت سوم است، زمانی که هشدار روشن می شود و پیام می فرستد.

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

برای مروری دقیق تر از رابط پرومتئوس، نگاه کنید در سخنرانی Slurm در مورد نظارت بر خوشه Kubernetes.

ادغام با Grafana

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

راه اندازی ادغام Prometheus و Grafana به هیچ وجه دشوار نیست؛ دستورالعمل ها را می توان در مستندات یافت: پشتیبانی GRAFANA برای پرومتئوسخوب، من با این تمام می کنم.

در مقاله های بعدی موضوع نظارت را ادامه خواهیم داد: در مورد جمع آوری و تجزیه و تحلیل لاگ ها با استفاده از Grafana Loki و ابزارهای جایگزین صحبت خواهیم کرد.

نویسنده: مارسل ابرایف، مدیر معتبر Kubernetes، مهندس شاغل در شرکت Southbridge، بلندگو و توسعه دهنده دوره Slurm.

منبع: www.habr.com