معرفی
پرومتئوس (Prometheus) یک ابزار متنباز برای پایش و هشداردهی است که متریکهای عددی سرویسها، سرورها، کانتینرها و برنامهها را بهصورت سری زمانی جمعآوری و در پایگاه داده سری زمانی خود ذخیره میکند. تیمها با زبان پرسوجوی PromQL وضعیت و روند شاخصهایی مانند مصرف CPU، حافظه، نرخ خطا، زمان پاسخ و تعداد درخواستها را بررسی میکنند. Prometheus برای نگهداری بلندمدت یا مقیاسپذیری بیشتر میتواند با سامانههای ذخیرهسازی خارجی نیز یکپارچه شود.
مدل رایج پرومتئوس «جمعآوری کششی» است. سرور Prometheus در بازههای مشخص به نقطه پایانی متریک یا endpoint مراجعه میکند و داده را میخواند. هر مقصدی که Prometheus برای جمعآوری داده میشناسد، target نام دارد و فرایند خواندن دورهای متریک scrape نامیده میشود.
برنامهها میتوانند متریک را مستقیماً منتشر کنند یا Exporterها داده ابزارها و زیرساخت را به قالب قابلخواندن پرومتئوس تبدیل کنند. برای نمونه، node_exporter متریک سیستمعامل و kube-state-metrics وضعیت منابع Kubernetes را منتشر میکنند.
مهندسان دواپس، SREها و توسعهدهندگان بکاند از Prometheus برای جمعآوری و تحلیل متریکها، ساخت داشبورد در ابزارهای مکمل، محاسبه شاخصهای سطح خدمت (SLI) و بررسی تحقق اهداف سطح خدمت (SLO) استفاده میکنند. Prometheus همچنین میتواند قوانین هشدار را ارزیابی کند، در حالی که دریافت، گروهبندی و مسیردهی اعلانها معمولاً با Alertmanager انجام میشود.
شروع عملی با یک نمونه آزمایشی
یک Prometheus محلی، برای مثال در Docker، اجرا کنید و رابط وب آن را باز کنید. سپس وضعیت سرویس و target مربوط به خود Prometheus را در بخش Targets بررسی کنید.
یک سرویس آزمایشی بسازید یا انتخاب کنید که endpoint متریک، مانند /metrics، منتشر میکند. موفقیت این مرحله زمانی است که endpoint در دسترس باشد و خروجی متریکها را نمایش دهد.
در فایل prometheus.yml یک scrape job اضافه کنید و نشانی سرویس را بهعنوان target وارد کنید. پس از بارگذاری تنظیمات، در صفحه Targets وضعیت target را بررسی کنید. اگر وضعیت DOWN بود، نشانی شبکه، پورت و دسترسی Prometheus به سرویس را بررسی کنید.
در بخش Query، پرسوجوی up را اجرا کنید تا وضعیت targetها را ببینید. سپس برای یک متریک Counter مانند شمارنده درخواستها، تابع rate() را روی یک بازه زمانی مانند ۵ دقیقه اجرا کنید. نتیجه قابلقبول، مشاهده یک سری زمانی و درک تفاوت مقدار تجمعی Counter با نرخ تغییر آن است.
یک alerting rule ساده برای در دسترس نبودن target تعریف کنید، مانند شرط up == 0 که برای چند دقیقه برقرار بماند. قانون را در رابط Prometheus بررسی کنید و با متوقف کردن سرویس آزمایشی، تغییر وضعیت هشدار از Pending به Firing را مشاهده کنید. برای ارسال اعلان واقعی، Alertmanager را به Prometheus متصل کنید.
از همان مرحله طراحی متریک، برچسبهای با cardinality کنترلشده انتخاب کنید. برچسبهایی مانند service و instance معمولاً قابل مدیریتاند، اما تعداد مقادیر هر label باید متناسب با مقیاس سامانه بررسی شود. شناسه کاربر، شناسه درخواست، آدرس ایمیل و URL دارای شناسه را بهعنوان label استفاده نکنید، زیرا هر ترکیب یکتای label یک سری زمانی جدید ایجاد میکند و میتواند مصرف حافظه، فضای ذخیرهسازی و هزینه پردازش پرسوجوها را بهشدت افزایش دهد.
انتخاب میان ابزارهای نزدیک
VictoriaMetrics میتواند برای ذخیرهسازی متریک در مقیاس بزرگتر یا نگهداری بلندمدت دادهها بررسی شود و در معماریهای مبتنی بر اکوسیستم Prometheus با آن یکپارچه شود. Prometheus نیز از Remote Write و Remote Read برای اتصال به سامانههای ذخیرهسازی خارجی پشتیبانی میکند. InfluxDB یک پایگاه داده سری زمانی با مدل داده و ابزارهای مخصوص خود است و زمانی میتواند انتخاب مناسبی باشد که نیازهای تیم با اکوسیستم آن هماهنگ باشد.
Zabbix بیشتر برای پایش زیرساخت، میزبانها، شبکه و سناریوهای عاملمحور کاربرد دارد. Prometheus در محیطهای سرویسمحور و Kubernetes و در معماریهایی که متریکهای برنامه و کشف خودکار targetها اهمیت دارند، انتخاب رایجی است. انتخاب ابزار باید بر اساس نوع داده، روش جمعآوری، مقیاس، دوره نگهداری و معماری موجود تیم انجام شود.
Prometheus جایگزین کامل سامانه ثبت لاگ یا رهگیری توزیعشده نیست. ابزارهایی مانند Loki برای لاگ و OpenTelemetry برای تولید و انتقال دادههای تلهمتری، از جمله متریک و trace، کاربرد دارند و میتوانند در یک معماری مشاهدهپذیری در کنار Prometheus استفاده شوند.
ویژگیهای کلیدی
موارد زیر تصویری کلی از این بخش برای این ابزار ارائه میکنند.
-
مدل داده سری زمانی و برچسبها
Prometheus دادهها را بهصورت سری زمانی ذخیره میکند. هر سری زمانی با نام متریک و مجموعه مشخصی از labelها شناسایی میشود و نمونههای آن شامل مقدار و زمان ثبت هستند. labelهایی مانند service و instance امکان فیلتر و گروهبندی دادهها را فراهم میکنند.
-
پرسوجو با PromQL
PromQL برای انتخاب، تجمیع و محاسبه روی سریهای زمانی طراحی شده است. محاسبه صدک زمان پاسخ به متریک مناسب، معمولاً histogram، و تابعهایی مانند histogram_quantile نیاز دارد؛ این کار برای هر نوع متریک ممکن نیست.
-
جمعآوری کششی متریک
Prometheus بهطور دورهای endpointهای متریک را scrape میکند. این مدل وضعیت targetهای پایش را آشکار میکند و مدیریت فهرست هدفها را با service discovery سادهتر میسازد.
-
اکوسیستم Exporter
Exporterها متریک سامانهها و ابزارهایی را که مستقیماً متریک را در قالب موردنیاز Prometheus ارائه نمیکنند، به endpoint قابل scrape تبدیل میکنند. برای نمونه، node_exporter متریکهای مربوط به سیستمعامل و سختافزار را منتشر میکند و Exporterهای دیگر میتوانند برای پایگاههای داده، وبسرورها و سامانههای مختلف استفاده شوند.
-
قوانین ثبت و هشدار
قانونهای ثبت، پرسوجوهای پرتکرار را از پیش محاسبه میکنند و قانونهای هشدار هنگام برقرار بودن یک شرط در بازه مشخص، هشدار ایجاد میکنند.
-
کشف خودکار هدفها
Prometheus میتواند targetهای پایش را از روشهای مختلف service discovery دریافت کند. برای نمونه، میتوان targetها را از فایل پیکربندی یا محیطهایی مانند Kubernetes کشف کرد. این قابلیت نیاز به ثبت دستی تمام مقصدها را کاهش میدهد و مدیریت پایش در محیطهای پویا را سادهتر میکند.
کاربردها
برای آشنایی بهتر با این ابزار، توجه به موارد زیر میتواند مفید باشد.
-
پایش سلامت سرویسهای وب و API
ثبت نرخ درخواست، خطاهای HTTP، زمان پاسخ و تعداد درخواستهای همزمان برای تشخیص کندی یا افزایش خطای یک سرویس.
-
پایش زیرساخت و سرورها
جمعآوری مصرف CPU، حافظه، دیسک، شبکه و وضعیت سرویسهای سیستمعامل از سرورها برای ظرفیتسنجی و تشخیص اختلال.
-
پایش کلاستر Kubernetes
بررسی وضعیت Deployment، Pod و سایر منابع Kubernetes، مصرف منابع و وضعیت Nodeها با استفاده از متریکهای مناسب و ابزارهایی مانند kube-state-metrics و node_exporter. این دادهها میتوانند برای تشخیص اختلال، ظرفیتسنجی و تعریف هشدار استفاده شوند.
-
هشدار برای رخدادهای عملیاتی
تعریف هشدار برای مواردی مانند افزایش پایدار نرخ خطا، پرشدن دیسک، در دسترس نبودن هدف پایش یا نزدیکشدن مصرف منابع به سقف تعیینشده.
-
اندازهگیری شاخصهای قابلیت اطمینان
محاسبه نرخ موفقیت درخواستها، تأخیر سرویس و دسترسپذیری برای ارزیابی SLI و پیگیری SLOها.
ابزارهای جایگزین
پرسشهای رایج درباره پرومتئوس
اگر درباره این ابزار پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
آیا Prometheus ابزار نمایش داشبورد است؟
رابط وب Prometheus برای اجرای پرسوجو و بررسی ساده داده مناسب است، اما تیمها معمولاً برای داشبوردهای عملیاتی از Grafana استفاده میکنند. Grafana داده را از Prometheus میخواند و جایگزین آن نیست.
Exporter در Prometheus چیست؟
Exporter برنامهای است که متریک یک سامانه را در endpoint سازگار با Prometheus منتشر میکند. وقتی برنامه یا ابزار شما متریک Prometheus ندارد، Exporter میتواند داده آن را قابل جمعآوری کند.
آیا Prometheus برای ذخیره لاگ مناسب است؟
خیر. Prometheus برای جمعآوری و ذخیره متریکهای عددی سری زمانی طراحی شده است، نه ذخیره متن لاگ. برای لاگ میتوان از ابزارهایی مانند Loki و برای رهگیری توزیعشده از ابزارهایی مانند OpenTelemetry استفاده کرد. این دادهها میتوانند در یک معماری مشاهدهپذیری در کنار متریکهای Prometheus قرار بگیرند.
چرا استفاده از user_id بهعنوان label خطرناک است؟
هر ترکیب یکتای label یک سری زمانی جدید میسازد. user_id، request_id یا URLهای دارای شناسه میتوانند تعداد سریها را بسیار زیاد کنند و حافظه، فضای دیسک و سرعت پرسوجو را تحت فشار بگذارند.
برای شروع Prometheus چه چیزهایی باید یاد بگیرم؟
ابتدا مفهوم متریک، label، endpoint، scrape و target را یاد بگیرید. سپس یک سرویس با endpoint متریک اجرا کنید، آن را در prometheus.yml به scrape job اضافه کنید و با دیدن وضعیت UP در صفحه Targets، اتصال را تأیید کنید. بعد PromQL، طراحی متریکهای کمکاردینالیتی و alert rule را تمرین کنید.
چگونه اولین هشدار Prometheus را آزمایش کنم؟
یک قانون برای down بودن target تعریف کنید که چند دقیقه برقرار بماند. ابتدا در صفحه Alerts معتبر بودن قانون را بررسی کنید، سپس سرویس آزمایشی را متوقف کنید. اگر هشدار از Pending به Firing رسید، ارزیابی قانون درست است. برای دریافت اعلان، Alertmanager را نیز تنظیم کنید.
Prometheus را انتخاب کنم یا VictoriaMetrics، InfluxDB و Zabbix را؟
Prometheus برای پایش متریک در محیطهای سرویسمحور و اکوسیستم Kubernetes گزینه رایجی است. اگر نیاز اصلی به مقیاس ذخیرهسازی یا نگهداری بلندمدت دادهها باشد، میتوان راهکارهایی مانند VictoriaMetrics یا سایر سامانههای سازگار با Remote Write را بررسی کرد. InfluxDB مدل داده و اکوسیستم مستقل خود را دارد و Zabbix برای پایش زیرساخت، میزبانها و شبکه گزینه مناسبی است. انتخاب نهایی باید بر اساس نوع داده، مقیاس، روش جمعآوری، دوره نگهداری و ابزارهای موجود تیم انجام شود.
آموزشهای مرتبط در فرادرس
-
آموزش مانیتورینگ در لینوکس Linux
-
آموزش مقدماتی مانیتورینگ شبکه با زبیکس Zabbix + گواهینامه
-
آموزش نتورک پلاس +Network و اصول شبکه + کاربردی و عملی + گواهینامه
-
آموزش ساخت اسکریپت مانیتورینگ وب سایت با پایتون + مدیریت خطا و هشداردهی هوشمند + گواهینامه
-
چگونه مهندس دواپس شویم؟، راهنمای مسیر شغلی DevOps
-
آموزش مانیتورینگ شبکه | راهنمای کامل و رایگان، به زبان ساده
