مقایسه Zabbix، Prometheus و Nagios: کدام ابزار مانیتورینگ برای شماست؟

در مقایسه Zabbix و Prometheus و Nagios، هر ابزار برای مسئله متفاوتی مناسب است. Zabbix برای مانیتورینگ یکپارچه سرور، تجهیزات شبکه و سرویس‌ها با رابط وب کامل ساخته شده، Prometheus برای محیط‌های پویا مانند Docker و Kubernetes با مدل pull و زبان PromQL، و Nagios Core برای بررسی‌های ساده «سالم یا خراب» در زیرساخت کوچک و پایدار.

جدول و بخش‌های زیر تفاوت عملی این سه ابزار را برای مدیران سرور و تیم‌های فنی، پیش از راه‌اندازی، مرور می‌کنند. اگر با مفاهیم پایه آشنا نیستید، ابتدا راهنمای مانیتورینگ سرور را بخوانید و برای آشنایی با گزینه‌های دیگر، معرفی ۱۰ ابزار مانیتورینگ سرور را ببینید. اطلاعات نسخه‌ها مربوط به شهریور ۱۴۰۵ است: Zabbix 7.0 LTS و 7.4 (نسخه 8.0 LTS طبق برنامه انتشار رسمی Zabbix در راه است)، Prometheus شاخه 3.x و Nagios Core شاخه 4.5.x.

جدول مقایسه Zabbix و Prometheus و Nagios

معماری و روش جمع‌آوری داده

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

Zabbix از چند بخش تشکیل شده است: Zabbix Server که داده‌ها را پردازش و Triggerها را ارزیابی می‌کند، پایگاه داده‌ای که پیکربندی و تاریخچه در آن ذخیره می‌شود، رابط وب، و ایجنت‌هایی (Zabbix agent یا agent 2) که روی سرورها نصب می‌شوند. ایجنت در دو حالت کار می‌کند: در حالت Passive، سرور به ایجنت وصل می‌شود و داده را درخواست می‌کند؛ در حالت Active، ایجنت فهرست بررسی‌ها را از سرور می‌گیرد و نتایج را خودش برای سرور یا Proxy می‌فرستد.

نقطه قوت Zabbix گستردگی روش‌های جمع‌آوری است: SNMP برای سوییچ و روتر، IPMI برای سخت‌افزار سرور، بررسی‌های HTTP و حتی خواندن متریک‌های قالب Prometheus با آیتم HTTP و پیش‌پردازش Prometheus pattern. Templateهای آماده و Low-Level Discovery هم دیسک‌ها، کارت‌های شبکه و سرویس‌ها را خودکار شناسایی می‌کنند. مراحل نصب را در آموزش کانفیگ سرور Zabbix روی اوبونتو ببینید.

Prometheus: مدل Pull و Exporterها

Prometheus به‌صورت دوره‌ای به آدرس HTTP هر هدف (معمولاً ‎/metrics) درخواست می‌فرستد و متریک‌ها را در پایگاه داده سری زمانی داخلی خود ذخیره می‌کند. هر متریک با نام و مجموعه‌ای از Label مشخص می‌شود و همین مدل چندبعدی، کوئری‌های انعطاف‌پذیر PromQL را ممکن می‌کند. برای سرویس‌هایی که خودشان متریک ارائه نمی‌دهند، Exporterها به کار می‌روند؛ مثلاً node_exporter متریک‌های CPU، حافظه، دیسک و شبکه لینوکس را روی پورت 9100 منتشر می‌کند.

# prometheus.yml
scrape_configs:
  - job_name: "node"
    scrape_interval: 30s
    static_configs:
      - targets: ["10.0.0.11:9100", "10.0.0.12:9100"]

در محیط‌های پویا، به جای فهرست ثابت از Service Discovery (مثلاً برای Kubernetes یا Consul) استفاده می‌شود تا هدف‌های جدید خودکار اضافه شوند. Prometheus ذخیره‌سازی توزیع‌شده داخلی ندارد و طبق مستندات رسمی Prometheus برای داده‌هایی که به دقت ۱۰۰ درصد نیاز دارند، مانند صورت‌حساب بر اساس تعداد درخواست، انتخاب مناسبی نیست. نصب و پیکربندی آن در آموزش نصب و کانفیگ Prometheus روی اوبونتو آمده است.

Nagios Core: پلاگین و وضعیت

Nagios Core یک زمان‌بند است که پلاگین‌ها را در فواصل مشخص اجرا می‌کند. هر پلاگین برنامه یا اسکریپتی مستقل است که با کد خروجی وضعیت را اعلام می‌کند: 0 برای OK، 1 برای WARNING، 2 برای CRITICAL و 3 برای UNKNOWN. همین سادگی باعث شده برای تقریباً هر سرویسی پلاگین آماده وجود داشته باشد یا بتوان آن را با چند خط اسکریپت نوشت. مسیر پلاگین‌ها در نصب از سورس معمولاً ‎/usr/local/nagios/libexec و در نصب از مخزن توزیع ‎/usr/lib/nagios/plugins است:

/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /
echo $?

برای بررسی منابع داخلی سرورهای دور، از ایجنت NRPE (برای لینوکس و یونیکس) یا NCPA (چندسکویی، روی ویندوز، لینوکس و macOS) استفاده می‌شود. تعریف Hostها، Serviceها و Contactها در فایل‌های متنی انجام می‌شود که برای زیرساخت کوچک قابل مدیریت است اما در مقیاس بزرگ بدون ابزار اتوماسیون دشوار می‌شود. راه‌اندازی آن را در آموزش نصب و کانفیگ Nagios روی اوبونتو ببینید.

اثر مدل Pull و Push بر شبکه و فایروال

مدل جمع‌آوری مستقیماً طراحی فایروال را تعیین می‌کند. در مدل Pull، سرور مانیتورینگ باید به همه هدف‌ها دسترسی شبکه داشته باشد؛ در مدل Push یا Active، هدف‌ها به سرور وصل می‌شوند و این برای شعب پشت NAT یا شبکه‌هایی که ورود ترافیک به آن‌ها محدود است ساده‌تر است. جدول زیر پورت‌های پیش‌فرض رایج را نشان می‌دهد:

Pushgateway را جایگزین مدل Pull نکنید؛ کاربرد آن کارهای کوتاه‌مدت مانند اسکریپت بکاپ یا Cron Job است که پیش از رسیدن نوبت Scrape تمام می‌شوند. در Zabbix برای شعب دور، Proxy محلی داده‌ها را جمع و به سرور مرکزی ارسال می‌کند و در زمان قطعی موقت ارتباط، داده‌ها را بافر می‌کند.

هشداردهی در Zabbix، Prometheus و Nagios

هشدار در Zabbix

در Zabbix، Trigger یک عبارت روی داده‌های جمع‌آوری‌شده است؛ مثلاً «فضای آزاد دیسک در ۵ دقیقه اخیر کمتر از ۱۰ درصد بوده است». وقتی Trigger فعال شود، Action تعیین می‌کند چه کسی، از چه کانالی و با چه ترتیبی مطلع شود. کانال‌های ارسال (Media Type) مانند ایمیل و Webhook برای پیام‌رسان‌هایی مثل Telegram به‌صورت آماده وجود دارند و قابلیت‌هایی مثل Escalation، دوره نگهداری (Maintenance) و وابستگی Triggerها از هشدارهای تکراری جلوگیری می‌کنند.

هشدار در Prometheus

در Prometheus، قاعده هشدار با PromQL نوشته می‌شود و Prometheus فقط تشخیص می‌دهد که شرط برقرار است؛ ارسال، گروه‌بندی، بی‌صدا کردن (Silence) و مسیریابی هشدار به گیرنده‌ها بر عهده برنامه جداگانه Alertmanager است. نمونه زیر وقتی یک فایل‌سیستم به مدت ۱۰ دقیقه بیش از ۹۰ درصد پر باشد هشدار می‌دهد:

groups:
  - name: node-alerts
    rules:
      - alert: DiskAlmostFull
        expr: (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) > 0.9
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Filesystem {{ $labels.mountpoint }} on {{ $labels.instance }} is over 90% full"

مزیت این مدل انعطاف بالای کوئری و نگهداری قاعده‌ها به‌صورت کد در کنار پروژه است؛ هزینه آن، نگهداری یک جزء اضافه و نیاز به تسلط تیم بر PromQL است.

هشدار در Nagios

Nagios با تغییر وضعیت یک Host یا Service (مثلاً از OK به CRITICAL) برای Contactهای تعریف‌شده Notification ارسال می‌کند. تشخیص نوسان وضعیت (Flapping)، وابستگی Host و Service برای جلوگیری از سیل هشدار هنگام قطعی یک سوییچ، و Escalation از قابلیت‌های داخلی آن هستند. روش ارسال خود یک Command است، بنابراین هر کانالی که بتوان با اسکریپت به آن پیام فرستاد قابل استفاده است.

داشبورد و نمایش داده با Grafana

Grafana لایه نمایش و داشبورد است و داده را از منابع مختلف می‌خواند. به همین دلیل کنار هر سه ابزار دیده می‌شود، ولی میزان یکپارچگی‌اش با هر کدام فرق دارد:

• Prometheus منبع داده داخلی Grafana است و بیشتر داشبوردهای آماده جامعه برای node_exporter و Kubernetes بر پایه آن ساخته شده‌اند. رابط وب خود Prometheus برای اجرای کوئری و بررسی سریع مناسب است و برای داشبورد عملیاتی ساخته نشده.
• Zabbix داشبورد، نمودار، گزارش و Network Map داخلی دارد که برای بسیاری از تیم‌ها کافی است. برای داشبوردهای ترکیبی، افزونه Zabbix برای Grafana که Grafana Labs آن را نگهداری می‌کند، متریک‌ها، Problemها و Triggerها را به Grafana می‌آورد.
• رابط وب Nagios Core وضعیت فعلی Host و Serviceها را نشان می‌دهد اما نمودار روند ندارد. برای نمودار، Performance Data آن را با ابزارهای جانبی به پایگاه داده سری زمانی مانند InfluxDB می‌فرستند و در Grafana نمایش می‌دهند.

برای کار عملی، آموزش نصب و کانفیگ Grafana، راهنمای ادغام Prometheus و Grafana و راه‌اندازی InfluxDB روی اوبونتو را ببینید.

مقیاس‌پذیری و هزینه نگهداری

Zabbix

در Zabbix، گلوگاه اصلی معمولاً پایگاه داده است؛ با افزایش تعداد آیتم‌ها و کوتاه شدن فاصله جمع‌آوری، حجم نوشتن روی دیتابیس بالا می‌رود. تنظیم دوره نگهداری History و Trend، استفاده از TimescaleDB روی PostgreSQL و توزیع بار جمع‌آوری با Zabbix Proxy راه‌های رایج مقیاس دادن آن هستند.

Prometheus

هر سرور Prometheus مستقل کار می‌کند و به‌صورت عمودی مقیاس می‌گیرد. مهم‌ترین عامل مصرف منابع، تعداد سری‌های زمانی (Cardinality) است؛ Labelهایی با مقادیر بسیار متنوع مانند شناسه کاربر می‌توانند حافظه را به‌سرعت پر کنند. برای نگهداری بلندمدت یا دید سراسری روی چند سرور Prometheus، از Federation یا Remote Write به سامانه‌هایی مانند Thanos، Grafana Mimir یا VictoriaMetrics استفاده می‌شود.

Nagios

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

انتخاب ابزار مانیتورینگ بر اساس سناریو

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

ترکیب ابزارها

بسیاری از سازمان‌ها بیش از یکی از این ابزارها را به کار می‌برند. الگوی رایج این است که Zabbix سرورها، تجهیزات شبکه و سرویس‌های سنتی را پوشش دهد، Prometheus کلاستر Kubernetes و اپلیکیشن‌ها را، و Grafana هر دو را در داشبوردهای مشترک نمایش دهد. در این حالت مسیر هشدارها را یکپارچه طراحی کنید تا یک رخداد از دو کانال و دو بار گزارش نشود.

جمع‌بندی مقایسه

هر سه ابزار متن‌بازند و برای مسائل متفاوتی طراحی شده‌اند. Zabbix برای زیرساخت ترکیبی رابط وب یکپارچه دارد، Prometheus در محیط‌های Cloud Native انتخاب رایج مانیتورینگ متریک است و Nagios Core برای بررسی‌های ساده وضعیت هنوز گزینه‌ای سبک است. پیش از تصمیم نهایی، ابزار منتخب را روی چند سرور واقعی خودتان و با هشدارهای واقعی آزمایش کنید.

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

آیا Prometheus جایگزین Zabbix است؟

نه لزوماً. Prometheus برای متریک‌های پویا و محیط‌های Cloud Native قوی‌تر است، اما مانیتورینگ SNMP، ویندوز و Network Map را به شکل یکپارچه Zabbix ندارد و برای این موارد به Exporterهایی مانند snmp_exporter و windows_exporter و ابزارهای جانبی نیاز دارد.

آیا Nagios هنوز ارزش راه‌اندازی دارد؟

برای زیرساخت کوچکی که فقط به بررسی در دسترس بودن سرویس‌ها و هشدار نیاز دارد، بله. اما اگر نمودار روند، کشف خودکار یا مدیریت از رابط وب می‌خواهید، Zabbix یا Prometheus گزینه‌های مناسب‌تری هستند.

آیا Grafana جایگزین این ابزارهاست؟

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

برای مانیتورینگ Kubernetes کدام مناسب‌تر است؟

Prometheus. Service Discovery داخلی برای Kubernetes، سازگاری با متریک‌های اجزای کلاستر و اکوسیستم گسترده Exporter و داشبورد، آن را به انتخاب رایج این محیط تبدیل کرده است. Zabbix هم Template مخصوص Kubernetes دارد، اما در محیط‌های بسیار پویا کمتر به کار می‌رود.

کدام ابزار منابع سخت‌افزاری کمتری مصرف می‌کند؟

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