معرفی پرومتئوس و بررسی روش نصب و تلفیق با گرافانا

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

مختصری از تاریخچه‌ی پرومتئوس

پرومتئوس در سال ۲۰۱۲ توسط مهندسان سابق SoundCloud با هدف پاسخگویی به نیازهای پیچیده مانیتورینگ سیستم‌های توزیع‌شده و مقیاس‌پذیر، توسعه یافت.
این پروژه به دلیل تمرکز بر جمع‌آوری داده‌های متریک از سرویس‌ها و ذخیره‌سازی آن‌ها به صورت سری‌های زمانی (Time-Series) به سرعت محبوب شد. در سال ۲۰۱۶، پرومتئوس به دومین پروژه بنیاد Cloud Native Computing Foundation پس از Kubernetes تبدیل شد، که جایگاه آن را به‌عنوان یکی از ابزارهای کلیدی در اکوسیستم Cloud Native تقویت کرد.
ویژگی‌های برجسته پرومتئوس شامل معماری بدون وابستگی (Standalone)، استفاده از زبان کوئری PromQL و ادغام ساده با سایر ابزارها و سرویس‌ها است. امروزه پرومتئوس به‌طور گسترده در صنایع مختلف برای مانیتورینگ سیستم‌ها، هشداردهی و تحلیل داده‌های متریک (Metric data analysis) استفاده می‌شود.

پرومتئوس چیست؟

پرومتئوس (Prometheus) یکی از ابزارهای متن‌باز و قدرتمند در حوزه نظارت است. از این سیستم برای نظارت و مانیتورینگ (Monitoring) سیستم‌ها، به‌ویژه در بخش داده‌های کلان (‌Big Data) و زیرساخت‌های مدرن مانند داکر (Docker Monitoring) و کوبرنتیز (Kubernetes Monitoring) استفاده می‌شود.

کاربرد پرومتئوس در دواپس (DevOps)

پرومتئوس با در نظر گرفتن تمام اطلاعاتی که تا این قسمت به‌دست آورده‌ایم، یکی از ابزارهای محبوب در دنیای دواپس (DevOps) است. دلایل این محبوبیت را می‌توان در موارد زیر یافت:

۱- ماهیت متن‌باز (Open-Source)

• Prometheus به‌عنوان یک پروژه متن‌باز از یک جامعه بزرگ و فعال بهره می‌برد.
• جامعه کاربران به راحتی می‌توانند آن را توسعه دهند. همین امر باعث بهبود مستمر آن شده‌است.
• مدل متن‌باز به این معناست که پرومتئوس بدون هزینه‌های لایسنس (License) در دسترس است، که آن را به گزینه‌ای جذاب برای سازمان‌هایی با اندازه‌های مختلف تبدیل می‌کند.

۲- انعطاف‌پذیری و مقیاس‌پذیری

• Prometheus به گونه‌ای طراحی شده که بسیار انعطاف‌پذیر (Flexible) و مقیاس‌پذیر (scalable) باشد.
• معماری ماژولار آن (که در قسمت بعدی به‌صورت مفصل آن را مورد بررسی قرار می‌دهیم)، امکان یکپارچه‌سازی آسان با انواع سیستم‌ها و خدمات را فراهم می‌کند.
• پرومتئوس توانایی مدیریت حجم بالای متریک‌ها و کاردینالیتی (Cardinality) بالا را دارد، که آن را برای پروژه‌های کوچک و زیرساخت‌های بزرگ و پیچیده مناسب می‌سازد.

معماری پرومتئوس و اجزای آن

پرومتئوس از لحاظ ساختار و معماری دارای اجزای مختلفی است که مهم‌ترین آن‌ها عبارت‌اند از:

• Prometheus Server (سرور پرومتئوس)
• Targets (اهداف)
• Time-Series Database (پایگاه داده‌ی سری زمانی)
• Exporters
• Service Discovery (کشف منابع)
• Pushgateways (درگاه‌های ارسال داده)
• Client Libraries (کتابخانه‌های کلاینت)
• Alert Manager (مدیریت هشدار)
• PromQL (زبان کوئری پرومتئوس)

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

۱- Prometheus Server

سرور پرومتئوس به‌عنوان مغز سیستم مانیتورینگ مبتنی بر متریک عمل می‌کند. وظیفه اصلی این سرور، جمع‌آوری متریک‌ها از اهداف مختلف با استفاده از Pull Model است. علاوه بر این، جمع‌آوری داده‌های متریک، ذخیره‌سازی داده‌ها و همچنین کوئری‌های مختلف، از جمله وظایفی است که سرور مسؤلیت انجام آن را بر عهده دارد.
منظور از هدف (Target)، سرور، پاد (Pod)، نقاط پایانی (Endpoints) و موارد مشابه است که در بخش‌های بعدی به‌صورت مفصل‌تر در مورد آن‌ها توضیح داده شده‌است. همچنین اصطلاح عمومی برای جمع‌آوری متریک‌ها از اهداف با استفاده از پرومتئوس، اسکرپینگ (Scraping) نامیده می‌شود.
شکل زیر می‌تواند به روشن‌تر شدن این موضوع کمک کند:

پرومتئوس به‌صورت دوره‌ای، متریک‌ها را بر اساس فاصله‌ی تعریف شده در فایل پیکربندی، اسکرپ می‌کند. در ادامه، یک نمونه از فایل پیکربندی نشان داده شده‌است:

global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_timeout: 10s

rule_files:
- "rules/*.rules"

scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node-exporter'
static_configs:
- targets: ['node-exporter:9100']

alerting:
alertmanagers:
- static_configs:
- targets: ['alertmanager:9093']

۲- TSDB (پایگاه داده‌ی سری زمانی)

داده‌های متریکی که Prometheus دریافت می‌کند (مانند CPU، حافظه، ورودی و خروجی (IO) شبکه و …)، در طول زمان تغییر می‌کند. این داده‌ها به‌صورت جفت‌های زمان – مقدار (Timestamp-Value) نگهداری می‌شوند. پرومتئوس به‌صورت پیش‌فرض، تمامی داده‌های خود را در یک قالب کارآمد به نام Chunks و روی فضای ذخیره‌سازی محلی (Local Storage) ذخیره می‌کند.
داده‌های قدیمی‌تر نیز برای صرفه‌جویی در فضا، فشرده‌تر می‌شوند. همچنین یک سیاست نگهداری (Retention Policy) هم در Prometheus وجود دارد که از آن برای حفظ داده‌های قدیمی‌تر استفاده می‌شود.
پایگاه داده سری زمانی پرومتئوس دارای مکانیزم‌های داخلی برای مدیریت داده‌هایی است که برای مدت طولانی ذخیره می‌شوند. شما می‌توانید یکی از سیاست‌های نگهداری زیر را انتخاب کنید:

• نگهداری مبتنی بر زمان: داده‌ها برای تعداد روز مشخصی نگهداری می‌شوند. به‌صورت پیش‌فرض، مدت زمان نگهداری ۱۵ روز است.
• نگهداری مبتنی بر حجم: شما می‌توانید حداکثر حجمی که پایگاه داده می‌تواند نگه دارد را تعیین کنید. زمانی که این حجم به حداکثر مقدار خود برسد، پرومتئوس فضا را آزاد می‌کند تا داده‌های جدید ذخیره شوند.

علاوه بر این، پرومتئوس گزینه‌هایی برای ذخیره‌سازی راه دور (Remote Storage) نیز ارائه می‌دهد. این قابلیت بیشتر برای مقیاس‌پذیری ذخیره‌سازی، نگهداری طولانی‌مدت داده‌ها، پشتیبان‌گیری (Backup) و بازیابی در مواقع بحرانی (Disaster Recovery) مورداستفاده قرار می‌گیرد.

۳- Targets

تارگت‌ها به منابعی گفته می‌شود که پرومتئوس متریک‌ها را از آن‌ها جمع‌آوری (Scrap) می‌کند. اهداف می‌توانند شامل سرورها، سرویس‌ها، پادهای (PODs) کوبرنتیز، End-Point برنامه‌ها و … باشند.

مسیر تمامی متریک‌ها به‌صورت پیش‌فرض در مسیر metrics/ قرار دارد. با این حال همین مسیر هم می‌تواند در تنظیمات Targets تغییر یابد. این تنظیمات در فایل پیکربندی پرومتئوس و در قسمت scrape_configs تعریف می‌شود. در ادامه، یک مثال از این پیکربندی ارائه شده‌است:

scrape_configs:

- job_name: 'node-exporter'
static_configs:
- targets: ['node-exporter1:9100', 'node-exporter2:9100']

- job_name: 'my_custom_job'
static_configs:
- targets: ['my_service_address:port']
metrics_path: '/custom_metrics'

- job_name: 'blackbox-exporter'
static_configs:
- targets: ['blackbox-exporter1:9115', 'blackbox-exporter2:9115']
metrics_path: /probe

- job_name: 'snmp-exporter'
static_configs:
- targets: ['snmp-exporter1:9116', 'snmp-exporter2:9116']
metrics_path: /snmp

۴- اسکپورترها (Exporters)

اسکپورترها مانند عواملی (Agent) عمل می‌کنند که روی تارگت‌ها اجرا می‌شوند. وظیفه‌ی اسکپورترها این است که متریک‌ها را از یک سیستم خاص به فرمت قابل فهم برای پرومتئوس تبدیل کنند. این متریک‌ها می‌توانند شامل متریک‌های سیستمی (مانند CPU، حافظه و …)، متریک‌های JAVA JMX، متریک‌های MySQL و یا موارد مشابه دیگر باشند.

متریک‌های تبدیل شده توسط اکسپورترها، به‌صورت پیش‌فرض در مسیر metrics/ قرار می‌گیرند.

به عنوان مثال برای نظارت بر CPU و حافظه‌ی سرور، باید یک Node Exporter روی آن سرور نصب کنید. این اکسپورتر، متریک‌های CPU و حافظه را در فرمت قابل فهم برای Prometheus، در مسیر metrics/ قرار می‌دهد. زمانی که پرومتئوس متریک‌ها را جمع‌آوری می‌کند، نام متریک، برچسب‌ها، مقدار و زمان ثبت داده‌ها را ترکیب می‌کند تا به داده‌ها ساختار مشخصی بدهد.

به این نکته هم توجه داشته باشید که تعداد زیادی اکسپورتر جامعه‌محور (Community Exporters) در دسترس هستند، اما تنها برخی از آن‌ها به‌طور رسمی توسط Prometheus تأیید شده‌اند. در مواردی که نیاز به سفارشی‌سازی بیشتری دارید، ممکن است نیاز به ایجاد اکسپورترهای اختصاصی داشته باشید.

Prometheus اکسپورترها را به بخش‌های مختلفی مانند پایگاه داده‌ها، سخت‌افزار، ابزارهای مدیریت موضوعات و یکپارچه‌سازی مداوم (CI)، سیستم‌های پیام‌رسانی، ذخیره‌سازی، نرم‌افزارهایی که متریک‌های پرومتئوس را ارائه می‌دهند و ابزارهای شخص ثالث دسته‌بندی کرده است.
فهرست اکسپورترهای هر دسته را می‌توانید در مستندات رسمی پرومتئوس مشاهده کنید.
جزئیات مربوط به تمام اکسپورترها در فایل پیکربندی پرومتئوس و در بخش scrape_configs تعریف می‌شود که نمونه‌ی آن را می‌توانید در ادامه مشاهده کنید:

scrape_configs:
- job_name: 'node-exporter'
static_configs:
- targets: ['node-exporter1:9100', 'node-exporter2:9100']

- job_name: 'blackbox-exporter'
static_configs:
- targets: ['blackbox-exporter1:9115', 'blackbox-exporter2:9115']
metrics_path: /probe

- job_name: 'snmp-exporter'
static_configs:
- targets: ['snmp-exporter1:9116', 'snmp-exporter2:9116']
metrics_path: /snmp

۵- کشف منابع (Service Discovery)

پرومتئوس برای جمع‌آوری متریک‌ها از اهداف (Targets) از دو روش استفاده می‌کند:

• پیکربندی استاتیک (Static Configs)

در صورتی که اهداف دارای آدرس IP ثابت یا نقطه پایانی DNS باشند، می‌توان این نقاط پایانی را به‌عنوان اهداف تعریف کرد.

• کشف منابع (Service Discovery)

در سیستم‌های مقیاس‌پذیر خودکار (Autoscaling) و سیستم‌های توزیع‌شده مانند Kubernetes، اهداف معمولاً نقطه پایانی ثابت ندارند. در این حالت، نقاط پایانی اهداف با استفاده از قابلیت کشف منابع پرومتئوس شناسایی شده و به‌صورت خودکار به پیکربندی آن اضافه می‌شوند.
بدون اینکه بخواهیم در مسائل فنی غرق شویم، در اینجا یک نمونه کوچک از بلوک کشف منابع Kubernetes در فایل پیکربندی پرومتئوس با استفاده از kubernetes_sd_configs آورده شده‌است:

scrape_configs:
- job_name: 'kubernetes-apiservers'
kubernetes_sd_configs:
- role: endpoints
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file:
/var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https

علاوه بر این دو روش، روش‌های دیگری نیز برای کشف منابع وجود دارند، از جمله:

• consul_sd_configs: در این روش، پرومتئوس جزئیات اهداف را از Consul دریافت می‌کند.
• ec2_sd_configs: استفاده از این روش برای برای منابع در AWS EC2 مناسب‌ است.

۶- درگاه‌های ارسال داده (Pushgateways)

همان‌طور که قبلاً هم به آن اشاره کردیم، پرومتئوس به‌طور پیش‌فرض از مکانیزم Pull برای جمع‌آوری متریک‌ها استفاده می‌کند. اما در برخی سناریوها نیاز است که متریک‌ها به‌جای اینکه توسط Prometheus جمع‌آوری شوند، به آن پوش (Push) شوند.
به‌عنوان مثال فرض کنید یک بچ‌ جاب (Batch Job) روی یک کرون‌ جاب (CronJob) در Kubernetes اجرا می‌شود و روزانه تنها ۵ دقیقه فعالیت می‌کند. در این حالت، Prometheus نمی‌تواند متریک‌های این سرویس را به‌درستی و به‌موقع جمع‌آوری کند. در چنین مواقعی، به‌جای اینکه منتظر باشیم پرومتئوس متریک‌ها را جمع‌آوری کند، باید این متریک‌ها به آن پوش شوند. برای این کار، پرومتئوس یک ابزار به نام Pushgateway ارائه می‌دهد که به‌عنوان یک درگاه واسط (Intermediate Gateway) عمل می‌کند.

نکته‌ی مهم این است که Pushgateway باید به‌صورت یک کامپوننت مستقل اجرا شود. بچ جاب‌ها می‌توانند متریک‌ها را از طریق HTTP API به Pushgateway ارسال کنند. سپس Pushgateway این متریک‌ها را از طریق یک مسیر مشخص (metrics/) در دسترس Prometheus قرار می‌دهد. در نهایت هم پرومتئوس متریک‌ها را از Pushgateway جمع‌آوری می‌کند.

Pushgateway متریک‌ها را به‌صورت موقت و مثل یک کش موقت، در حافظه ذخیره می‌کند. همچنین Pushgateway در بخش scrape_configs فایل تنظیمات Prometheus تعریف می‌شود:

scrape_configs:
- job_name: "pushgateway"
honor_labels: true
static_configs:
- targets: [pushgateway.monitoring.svc:9091]

برای ارسال متریک‌ها، باید از کتابخانه‌های کلاینت پرومتئوس (Prometheus Client Libraries) استفاده کنید. این کتابخانه‌ها برای ابزارسازی (Instrumentation) برنامه‌ها یا اسکریپت‌ها (Scripts) طراحی شده‌اند تا متریک‌های موردنیاز را در قالبی که پرومتئوس می‌فهمد ارائه دهند. به‌عنوان مثال در یک برنامه Python، می‌توانید متریکی به نام batch_job_records_processed_total ایجاد و از طریق Pushgateway منتشر کنید.

۷- کتابخانه‌های کلاینت (Client Libraries)

کتابخانه‌های کلاینت مجموعه‌ای از کتابخانه‌های نرم‌افزاری هستند که می‌توان از آن‌ها برای ابزارگذاری (Instrumentation) کد برنامه استفاده کرد تا متریک‌ها به صورتی که پرومتئوس بتواند آن‌ها را درک کند، در دسترس قرار بگیرند.
استفاده از این کتابخانه‌ها، به‌خصوص در مواردی کاربردی است که نیاز به ابزارگذاری سفارشی و یا اکسپورترهای خاصی داشته باشید. به‌عنوان مثال، یکی از کاربردی‌ترین زمان‌هایی که کتابخانه‌های کلاینت (Client Library) به کمک‌مان می‌آیند، زمانی است که بچ جاب‌ها نیاز به ارسال متریک‌ها به Pushgateway دارند. در این شرایط، بچ جاب باید با استفاده از کتابخانه‌های کلاینت ابزارگذاری شود تا بتواند متریک‌های موردنیاز را در فرمت پرومتئوس ارائه دهد.
در مثال زیر، یک کتابخانه کلاینت پایتون برای ارائه متریک‌های سفارشی با نام batch_job_records_processed_total استفاده شده‌است:

from prometheus_client import start_http_server, Counter
import time
import random

# تعریف متریک شمارنده
RECORDS_PROCESSED = Counter('batch_job_records_processed_total', 'Total number of records processed by the batch job')

def process_record():
time.sleep(random.uniform(0.01, 0.1)) # شبیه‌سازی پردازش رکوردها
RECORDS_PROCESSED.inc() # افزایش مقدار متریک

def batch_job():
for _ in range(100): # اجرای بچ جاب برای 100 رکورد
process_record()

if __name__ == '__main__':
start_http_server(8000) # شروع سرور HTTP برای ارائه متریک‌ها
print("Metrics server started on port 8000")

batch_job() # اجرای وظیفه دسته‌ای
print("Batch job completed")

while True:
time.sleep(1) # نگه‌داشتن سرور در حالت اجرا

نکات تکمیلی زیر را هم در مورد کتابخانه‌های کلاینت، در نظر داشته باشید:

• زمانی که از کتابخانه‌های کلاینت استفاده می‌کنید، سرور HTTP ارائه‌شده توسط prometheus_client متریک‌ها را در مسیر metrics/ ارائه می‌دهد.
• پرومتئوس برای تقریباً تمامی زبان‌های برنامه‌نویسی، کتابخانه کلاینت دارد.
• اگر هیچ کدام از کتابخانه‌های موجود پاسخ‌گوی نیاز شما نبودند، می‌توانید کتابخانه‌ی سفارشی خودتان را بسازید. برای اطلاعات بیشتر در این زمینه و مشاهده‌ی لیست کتابخانه‌های موجود، می‌توانید به داکیومنت‌‌های رسمی پرومتئوس مراجعه کنید.

۸- مدیریت هشدار (Alert Manager)

Alert manager یکی از اجزای کلیدی سیستم مانیتورینگ پرومتئوس است و وظیفه‌ی اصلی آن، ارسال هشدارها بر اساس مرزهای متریک تعریف‌شده در تنظیمات هشدار Prometheus است. اگر بخواهیم مراحل عملکرد این سیستم را خیلی ساده و مختصر توضیح دهیم، می‌توانیم به سه گام اساسی اشاره کنیم:

• پس از عبور از مرزهای متریک، سیستم هشداردهی پرومتئوس فعال می‌شود.
• این هشدارها به مکانیزم Alertmanager ارسال می‌شوند.
• Alertmanager هشدارها را به سیستم‌های اعلان (مانند ایمیل، Slack و …) ارسال می‌کند که این موضوع و نحوه‌ی اعلان هم در تنظیمات مشخص شده‌اند.

وظایف اصلی سیستم مدیریت هشدار را می‌توان در ۵ قسمت اصلی دسته‌بندی کرد:

• حذف هشدارهای تکراری (Alert Deduplicating): فرایندی برای خاموش کردن هشدارهای تکراری و جلوگیری از ارسال مکرر آن‌ها.
• گروه‌بندی (Grouping): گروه‌بندی هشدارهای مرتبط برای ارائه اطلاعات منظم‌تر.
• خاموش کردن هشدارها (Silencing): خاموش کردن هشدارها در مواقعی مانند تعمیر و نگهداری یا زمانی که هشدارها به‌صورت کاذب، مثبت هستند.
• مسیریابی (Routing): ارسال هشدارها به دریافت‌کنندگان مناسب بر اساس سطح شدت آن‌ها.
• مهار هشدارها (Inhibition): جلوگیری از ارسال هشدارهای کم‌اهمیت در زمانی‌که هشدارهایی با شدت متوسط یا بالا فعال هستند.

کلیات این روند در شکل زیر نشان داده شده‌است:

در ادامه، یک مثال از قانون هشدار برای نظارت بر تاخیر در میکروسرویس‌ (Micro service) آورده شده‌است:

groups:
- name: microservices_alerts
rules:
- record: http_latency:average_latency_seconds
expr: sum(http_request_duration_seconds_sum) / sum(http_request_duration_seconds_count)
- alert: HighLatencyAlert
expr: http_latency:average_latency_seconds > 0.5
for: 5m
labels:
severity: critical
annotations:
summary: "High latency detected in microservices"
description: "The average HTTP latency is high ({{ $value }} seconds) in the microservices cluster."
نمونه‌ی پیکربندی مسیریابی فایل پیکربندی Alertmanager هم در ادامه ارائه شده‌است:
routes:
- match:
severity: 'critical'
receiver: 'pagerduty-notifications'

- match:
severity: 'warning'
receiver: 'slack-notifications'

۹- زبان کوئری PromQL

زبان PromQL یک زبان کوئری انعطاف‌پذیر است که می‌تواند برای متریک‌های سری زمانی از پرومتئوس استفاده شود. برای استفاده از این زبان، هم می‌توانید به‌صورت مستقیم از کوئری‌های قرار گرفته در رابط کاربری و هم از دستور Curl در رابط خط فرمان استفاده کنیم. در شکل زیر، رابط کاربری Prometheus نشان داده شده‌است:

کد زیر هم نمونه‌ی استفاده از دستور Curl را نشان می‌دهد:

curl "http://54.186.154.78:30000/api/v1/query?query=$(echo 'up' | jq -s -R -r @uri)" | jq .

همچنین هنگامی که پرومتئوس را به‌عنوان منبع داده (Data Source) به گرافانا اضافه کنید، می‌توانید از PromQL برای کوئری زدن و ایجاد داشبوردهای گرافیکی استفاده کنید که نمونه‌ی آن در شکل زیر نشان داده شده‌است:

مزایا و معایب استفاده از پرومتئوس

پرومتئوس هم مانند هر ابزار دیگری، مزایا و معایبی دارد. توجه به این موارد است که می‌تواند متخصص دواپس (DevOps) را به این نتیجه برساند که آیا استفاده از این ابزار در پروژه‌، کاربردی است یا باید از ابزارهای دیگری استفاده کرد.

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

استفاده از پرومتئوس مزایای متعددی دارد که از جمله مهم‌ترین آن‌ها می‌توان به موارد زیر اشاره کرد:

۱- مانیتورینگ با پرومتئوس

پرومتئوس داده‌ها را به‌صورت سری زمانی و همراه با تاریخ و ساعت دقیق ثبت می‌کند. این ویژگی به کاربر این امکان را می‌دهد تا عملکرد سیستم خود را در هر لحظه رصد کرده و مشکلات را سریع‌تر شناسایی کند.

۲- استفاده از مدل داده‌ی چند بعدی (Multidimensional Data Model)

یکی دیگر از مزایای پرومتئوس این است که به شما اجازه می‌دهد تا دسته‌بندی داده‌ها را با استفاده از برچسب‌ها انجام دهید. این قابلیت باعث می‌شود بتوانید اطلاعات را به‌راحتی فیلتر و تحلیل کنید؛ به‌عنوان مثال می‌توانید مصرف منابع هر سرور را به‌صورت جداگانه بررسی کنید.

۳- زبان کوئری پرومتئوس

با استفاده از زبان کوئری پرومتئوس (PromQL) که در قسمت قبلی هم توضیحاتی در مورد آن ارائه شد، می‌توانید با استفاده از کوئری‌های دقیق و پیشرفته، اطلاعات موردنیاز را در کوتاه‌ترین زمان ممکن، پیدا کنید. به‌عنوان مثال با استفاده از این زبان می‌توانید مصرف CPU را در یک بازه‌ی زمانی خاص، مشاهده کنید.

۴- مستقل بودن از ذخیره‌سازی توزیع شده (Distributed Storage)

پرومتئوس برای ذخیره‌سازی، نیازی به سیستم‌های پیچیده و بزرگ ندارد؛ به‌عبارت دیگر هر سرور به‌صورت مستقل عمل می‌کند. این ویژگی باعث می‌شود که کار با این ابزار ساده‌تر و قابل اعتمادتر باشد.

۵- شناسایی خودکار سرویس‌ها

پرومتئوس می‌تواند به‌صورت خودکار، سرویس‌ها و منابع جدید را شناسایی کند. به‌عبارت دیگر نیازی ندارید تا سرویس‌ها را به‌صورت دستی اضافه کنید. این ویژگی به‌ویژه در محیط‌های داینامیک مانند کوبرنتیز، بسیار مفید است.

۶- سیستم هشداردهی (Alerting) قدرتمند

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

۷- تصویرسازی داده‌ها

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

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

استفاده از پرومتئوس، معایبی هم دارد که از جمله مهم‌ترین آن‌ها می‌توان به موارد زیر اشاره کرد:

۱- عدم پشتیبانی از ذخیره‌سازی طولانی مدت

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

۲- استفاده‌ از Pull Model برای جمع‌آوری داده‌ها

پرومتئوس معمولاً داده‌ها را با Pull Model جمع‌آوری می‌کند. به‌عبارت دیگر خود Prometheus باید داده‌ها را از سرویس‌ها بگیرد. بنابراین اگر بخواهید داده‌هایی را به سرویس‌ها ارسال کنید، نیاز به یک سری تنظیمات اضافی و استفاده از یک Gateway دارید.

۳- لزوم استفاده از پرومتئوس و گرافانا برای داشبوردسازی

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

۴- نیاز به منابع قدرتمند برای تعداد زیاد متریک‌ها

در صورتی‌که متریک‌های (Metrics) جمع‌آوری شده توسط پرومتئوس زیاد باشد، ممکن است به منابع بالایی در سرور نیاز داشته باشید که این موضوع می‌تواند در اقتصاد پروژه اثرگذار باشد.

۵- نیاز به تنظیمات پیچیده

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

نصب و راه‌ اندازی پرومتئوس

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

گام اول: دانلود پرومتئوس و Node_Exporter

در مرحله‌ی اول، لازم است فایل‌های Prometheus و Node_Exporter را دانلود کنیم. نحوه‌ی نصب Node Exporter نیز در داکیومنت‌های پرومتئوس به‌صورت واضح ارائه شده‌است: https://prometheus.io/docs/guides/node-exporter/#installing-and-running-the-node-exporter

گام دوم: نصب پرومتئوس

بعد از دانلود، مراحل زیر را به ترتیب انجام دهید:

۱- بعد از دانلود پرومتئوس، فایل‌های فشرده‌ی دانلود شده را Extract کرده و به دایرکتوری آن بروید:

tar xvfz prometheus-*.tar.gz
cd prometheus-*

۲- فایل prometheus.yml را در این دایرکتوری پیدا کنید.

۳- فایل پیکربندی پرومتئوس را طوری تغییر دهید که میزبان‌هایی که روی آن‌ها node_exporter نصب کرده‌اید را مانیتور کند. توجه داشته باشید که به‌صورت پیش‌فرض، Prometheus به دنبال فایل prometheus.yml در دایرکتوری جاری می‌گردد. این رفتار را می‌توانید با استفاده از دستور –config.file در خط فرمان تغییر دهید. برای مثال، برخی نصب‌کننده‌ها فایل پیکربندی را در مسیر /etc/prometheus/prometheus.yml قرار می‌دهند.

به‌عنوان مثال فایل پیکربندی زیر نشان می‌دهد که چطور می‌توانید تنظیمات لازم را اضافه کنید. توجه کنید که هدف‌ها (Targets) به صورت [‘localhost:9100’] تنظیم شده‌اند تا Node_Exporter در حالت اجرای محلی هدف قرار گیرد:

scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']

۴- پرومتئوس را با استفاده از دستور زیر، اجرا کنید:

./prometheus --config.file=./prometheus.yml

۵- برای تأیید اجرا، به آدرس http://localhost:9090 بروید تا مطمئن شوید که Prometheus در حال اجرا است. در این آدرس می‌توانید متریک‌های Node_Exporter را نیز بررسی و از درست بودن آن‌ها، مطمئن شوید.

گام سوم: تلفیق پرومتئوس و گرافانا

برای استفاده از پرومتئوس در گرافانا، دو راهکار اساسی وجود دارد:

• استفاده از گرافانای میزبانی شده در Grafana Cloud
• اجرای گرافانا به‌صورت محلی (Local)

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

۱- در سایت Grafana با آدرس https://grafana.com/ ثبت‌نام کنید.

در این‌صورت گرافانا به شما یک نمونه‌ی آماده از پرومتئوس را ارائه می‌کند و با توجه به اینکه شما Prometheus را به‌صورت محلی اجرا می‌کنید، باید داده‌های خود را به این نمونه در Grafana Cloud ارسال کنید.
۲- سپس باید پیکربندی ارسال داده‌ها را انجام دهید. برای این منظور، گرافانا کدی ارائه می‌دهد که باید آن را به فایل prometheus.yml اضافه کنید. این کد شامل آدرس remote_write، نام کاربری و همچنین رمز عبور شما است. نمونه‌ی این کد را می‌توانید در ادامه ببینید:

remote_write:
- url: <https://your-remote-write-endpoint>
basic_auth:
username: <your user name>
password: <Your Grafana.com API Key>

۳- برای مشاهده‌ی متریک‌ها در گرافانا، به بخش Explore بروید. سپس کوئری‌های مختلفی را برای متریک‌ها ایجاد و داده‌های مانیتور شده را بررسی کنید. در صورتی‌که ایرادی هم در این مسیر پیدا کردید، باید روند عیب‌یابی را بر اساس Errorهای مشاهده شده، انجام دهید و آن‌ها را رفع کنید.

۴- سپس می‌توانید داشبوردهایی را برای نمایش متریک‌ها در گرافانا ایجاد کنید. خوشبختانه مدل‌های آماده شده‌ای در گرافانا وجود دارد که می‌توانید از آن‌ها استفاده کنید. در شکل زیر، نمونه‌ای از یک داشبورد را مشاهده کنید که سه پنل مختلف دارد:

جمع‌بندی

پرومتئوس یک ابزار کاربردی برای مانیتورینگ و هشداردهی در شبکه‌های مختلف است که به‌صورت گسترده توسط متخصصین دواپس (DevOps) مورداستفاده قرار می‌گیرد. اما چطور می‌توان این ابزار را نصب و راه‌اندازی کرد؟ برای بصری کردن متریک‌های مختلف و قرار دادن آن‌ها در داشبوردها، چطور می‌توان از گرافانا استفاده کرد؟‌ در این مطلب از بلاگ پارس پک در مورد این مفاهیم، آموزش کامل ارائه شده‌است.

سؤالات متداول

پرومتئوس چیست و چه کاربردی دارد؟

پرومتئوس یک ابزار متن‌باز برای مانیتورینگ و هشداردهی است که بر اساس متریک‌ها و داده‌های سری زمانی کار می‌کند. این ابزار در جمع‌آوری داده‌ها از منابع مختلف و تحلیل آن‌ها برای شناسایی مشکلات در سیستم‌ها و زیرساخت‌ها بسیار مفید است.

چگونه Prometheus و گرافانا با یکدیگر کار می‌کنند؟

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

چرا پرومتئوس در DevOps محبوب است؟

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

چه محدودیت‌هایی در استفاده از Prometheus وجود دارد؟

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

چه آینده‌ای برای Prometheus وجود دارد؟

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