زیرساخت‌های مانیتورینگ سازمانی: بررسی Zabbix Prometheus و Grafana

پادکست زیرساخت‌های مانیتورینگ سازمانی: بررسی Zabbix Prometheus و Grafana

۱. مقدمه: فلسفه نوین مشاهده‌پذیری (Observability) و پایش زیرساخت

در چشم‌انداز پیچیده فناوری اطلاعات مدرن، مفهوم مانیتورینگ از یک فعالیت جانبی و واکنشی به یک رکن اساسی و استراتژیک در پایداری کسب‌وکار تبدیل شده است. مانیتورینگ سرور دیگر تنها به معنای بررسی “زنده بودن” (Up/Down) یک سیستم نیست؛ بلکه فرآیندی پیچیده برای دستیابی به “مشاهده‌پذیری” (Observability) کامل است. مشاهده‌پذیری به ما اجازه می‌دهد تا با بررسی خروجی‌های یک سیستم (لاگ‌ها، متریک‌ها و تریس‌ها)، وضعیت داخلی آن را درک کنیم. این گزارش فنی با هدف ارائه یک مرجع جامع و تخصصی برای مهندسان سیستم، مدیران زیرساخت و متخصصان DevOps تدوین شده است تا با بررسی عمیق سه ابزار استاندارد صنعت—Zabbix، Prometheus و Grafana—راهکارهای عملی و دقیقی برای پایش منابع حیاتی سرور (CPU، RAM، دیسک و شبکه) ارائه دهد.¹

۱.۱. تکامل از مانیتورینگ سنتی به مدرن

در دهه‌های گذشته، ابزارهای مانیتورینگ متمرکز بر بررسی وضعیت سخت‌افزار و سیستم‌عامل بودند. اما با ظهور معماری‌های میکروسرویس (Microservices)، کانتینرها (Containers) و زیرساخت‌های ابری (Cloud-Native)، نیاز به ابزارهایی احساس شد که بتوانند با پویایی این محیط‌ها سازگار شوند. در حالی که Zabbix به عنوان نماینده بلوغ و ثبات در مانیتورینگ زیرساخت‌های سنتی و ترکیبی شناخته می‌شود، Prometheus به عنوان استاندارد واقعی (De-facto Standard) برای محیط‌های کلاود و کوبرنتیز (Kubernetes) ظهور کرده است.¹ Grafana نیز به عنوان لایه‌ای بی‌طرف و قدرتمند برای بصری‌سازی، این دو دنیا را به هم پیوند می‌دهد. درک عمیق تمایزات فلسفی و فنی این ابزارها، پیش‌نیاز هرگونه تصمیم‌گیری معماری است.

۱.۲. اهداف و دامنه گزارش

این سند فراتر از یک راهنمای نصب ساده است. هدف، کالبدشکافی معماری داخلی ابزارها، بررسی دقیق مکانیزم‌های جمع‌آوری داده، و تحلیل استراتژی‌های بهینه برای نظارت بر منابع است. ما نه تنها به “چگونگی” (How) نصب و پیکربندی می‌پردازیم، بلکه به “چرایی” (Why) انتخاب هر پیکربندی و تأثیر آن بر عملکرد کلی سیستم نیز خواهیم پرداخت. تمرکز ویژه بر چهار منبع اصلی—پردازنده، حافظه، ذخیره‌سازی و شبکه—خواهد بود که ستون فقرات عملکرد هر سروری را تشکیل می‌دهند.³

۲. تحلیل تطبیقی معماری: رویارویی پارادایم‌های Push و Pull

انتخاب بین Zabbix و Prometheus اغلب به درک تفاوت بنیادین در نحوه جریان داده‌ها بازمی‌گردد. این تفاوت در معماری، تأثیرات عمیقی بر مقیاس‌پذیری، امنیت و پیچیدگی عملیاتی دارد.

۲.۱. معماری Zabbix: مدل سلسله‌مراتبی و ترکیبی

Zabbix بر پایه یک معماری متمرکز (Centralized) بنا شده است که در آن یک سرور مرکزی (Zabbix Server) مسئولیت اصلی جمع‌آوری، پردازش و ذخیره‌سازی داده‌ها را بر عهده دارد.

• پایگاه داده رابطه‌ای (RDBMS): زبیکس از دیتابیس‌های SQL مانند MySQL یا PostgreSQL برای ذخیره داده‌ها استفاده می‌کند. این ویژگی باعث می‌شود که داده‌ها ساختاریافته و با ثبات باشند، اما در مقیاس‌های بسیار بزرگ (صدها هزار متریک در ثانیه)، دیتابیس می‌تواند به گلوگاه (Bottleneck) تبدیل شود.⁵
• انعطاف‌پذیری در جمع‌آوری داده (Push & Pull): زبیکس از هر دو روش پشتیبانی می‌کند. در حالت Passive Check (مدل Pull)، سرور از ایجنت درخواست داده می‌کند. در حالت Active Check (مدل Push)، ایجنت به صورت مستقل داده‌ها را جمع‌آوری کرده و به سرور ارسال می‌کند. این ویژگی Zabbix Active Agent را برای محیط‌هایی که پشت NAT یا فایروال قرار دارند، بسیار کارآمد می‌سازد.⁵
• پروکسی‌های توزیع‌شده (Zabbix Proxy): برای حل مشکل مقیاس‌پذیری و پایش شبکه‌های ایزوله، زبیکس از کامپوننت Proxy استفاده می‌کند که بار پردازشی را از دوش سرور اصلی برداشته و داده‌ها را بافر می‌کند.

۲.۲. معماری Prometheus: مدل دموکراتیک و Cloud-Native

Prometheus با فلسفه‌ای کاملاً متفاوت طراحی شده است که ریشه در سیستم Borgmon گوگل دارد. این سیستم برای محیط‌هایی طراحی شده که در آن سرورها و سرویس‌ها به طور مداوم در حال تغییر، ایجاد و نابودی هستند.

• مدل Pull-Based خالص: در این مدل، پرومتئوس مسئولیت اتصال به اهداف (Targets) و فراخوانی داده‌ها (Scraping) را بر عهده دارد. کلاینت‌ها (Exporters) تنها داده‌ها را روی یک پورت HTTP در دسترس قرار می‌دهند. این رویکرد باعث می‌شود که کلاینت‌ها بسیار سبک باشند و منطق پیچیده‌ای نداشته باشند.¹
• پایگاه داده سری زمانی (TSDB): پرومتئوس از یک موتور ذخیره‌سازی محلی بسیار بهینه برای داده‌های سری زمانی استفاده می‌کند. این موتور برای نوشتن حجم عظیمی از داده‌ها با سرعت بالا طراحی شده است، اما بر خلاف SQL، برای کوئری‌های رابطه‌ای پیچیده مناسب نیست.
• عدم تمرکز (Decentralization): در معماری پرومتئوس، معمولاً چندین سرور پرومتئوس به صورت مستقل اجرا می‌شوند (مثلاً یک سرور برای هر کلاستر کوبرنتیز) و داده‌ها در لایه نمایش (Grafana) یا از طریق ابزارهایی مانند Thanos تجمیع می‌شوند.⁸

۲.۳. جدول تحلیل مقایسه‌ای عمیق

۳. کالبدشکافی و پیاده‌سازی Zabbix 7.0 LTS

نسخه ۷.۰ زبیکس (LTS) نقطه عطفی در تاریخ این نرم‌افزار است که با معرفی ویژگی‌هایی مانند High Availability (HA) بومی و بهبود عملکرد Proxy، جایگاه خود را تثبیت کرده است. در این بخش، فرآیند نصب و پیکربندی دقیق آن را بر روی سیستم‌عامل اوبونتو ۲۲.۰۴/۲۴.۰۴ بررسی می‌کنیم.

۳.۱. آماده‌سازی زیرساخت و پیش‌نیازها

برای راه‌اندازی یک سرور Zabbix پایدار، انتخاب سخت‌افزار مناسب حیاتی است. برای مانیتورینگ حدود ۵۰۰ هاست و ۲۰۰۰۰ آیتم، پیشنهاد می‌شود:

• CPU: حداقل ۴ هسته (ترجیحاً فرکانس بالا برای پردازش Triggerها).
• RAM: حداقل ۸ گیگابایت (برای کش دیتابیس و بافرهای داخلی زبیکس).
• Disk: حافظه SSD پرسرعت با I/O بالا، زیرا دیتابیس زبیکس به شدت I/O-Intensive است.

۳.۲. نصب گام‌به‌گام سرور (Zabbix Server)

گام اول: پیکربندی مخازن رسمی

استفاده از مخازن پیش‌فرض اوبونتو توصیه نمی‌شود زیرا معمولاً نسخه‌های قدیمی را شامل می‌شوند. مخزن رسمی Zabbix را نصب کنید:

Bash

# دانلود و نصب پکیج مخزن برای Ubuntu 22.04
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-1+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_7.0-1+ubuntu22.04_all.deb
sudo apt update

⁶

گام دوم: نصب ماژول‌ها

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

Bash

sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-nginx-conf zabbix-sql-scripts zabbix-agent

تحلیل: پکیج zabbix-sql-scripts حاوی اسکیمای دیتابیس است که برای راه‌اندازی اولیه حیاتی است.¹⁰

گام سوم: مهندسی پایگاه داده (MySQL/MariaDB)

پیکربندی صحیح دیتابیس مهم‌ترین بخش نصب است. کاراکترست utf8mb4 و Collation باینری utf8mb4_bin برای پشتیبانی صحیح از متن‌ها (حساسیت به حروف بزرگ و کوچک در تریگرها) الزامی است:

Bash

sudo mysql -uroot -p

SQL

-- ایجاد دیتابیس با تنظیمات استاندارد
CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'StrongPassword123!';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';
SET GLOBAL log_bin_trust_function_creators = 1; -- مورد نیاز برای ایمپورت اولیه توابع
QUIT;

سپس، تزریق اسکیمای اولیه:

Bash

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

پس از ایمپورت موفق، حتماً گزینه log_bin_trust_function_creators را در دیتابیس غیرفعال کنید.⁶

گام چهارم: تنظیمات فایل پیکربندی سرور

فایل /etc/zabbix/zabbix_server.conf مغز متفکر سرور است. پارامترهای زیر را تنظیم کنید:

Ini, TOML

DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=StrongPassword123!
CacheSize=512M      # افزایش حافظه کش برای عملکرد بهتر
HistoryCacheSize=128M
TrendCacheSize=128M
StartPollers=10     # تعداد فرآیندهای جمع‌آوری داده
StartTrappers=10    # برای دریافت داده‌های Active Agent و Sender

نکته تخصصی: مقادیر Cache باید متناسب با RAM سرور تنظیم شوند. تنظیمات پیش‌فرض برای محیط‌های پروداکشن بسیار کم هستند.⁶

گام پنجم: پیکربندی وب‌سرور Nginx

فایل /etc/zabbix/nginx.conf را ویرایش کرده و پورت و نام دامین را تنظیم کنید:

Nginx

listen 80;
server_name monitoring.example.com;

سپس سرویس‌ها را ریستارت کنید:

Bash

sudo systemctl restart zabbix-server zabbix-agent nginx php8.1-fpm
sudo systemctl enable zabbix-server zabbix-agent nginx php8.1-fpm

۳.۳. استراتژی‌های نصب و پیکربندی Zabbix Agent

برای جمع‌آوری داده از سرورهای هدف، Zabbix Agent باید نصب شود.

تفاوت Agent Classic و Agent 2:

• Zabbix Agent (C): نسخه کلاسیک، بسیار سبک و پایدار.
• Zabbix Agent 2 (Go): نسخه مدرن که از پلاگین‌ها پشتیبانی می‌کند، کانکشن‌های TCP کمتری باز می‌کند (Persistent connections) و برای مانیتورینگ دیتابیس‌ها و سرویس‌های وب بدون نیاز به اسکریپت خارجی بسیار قدرتمندتر است. پیشنهاد ما استفاده از Agent 2 برای تمامی نصب‌های جدید است.¹²

نصب Agent 2 بر روی کلاینت:

Bash

sudo apt install zabbix-agent2

پیکربندی /etc/zabbix/zabbix_agent2.conf:

Ini, TOML

Server=192.168.1.100       # آدرس سرور زبیکس برای درخواست‌های Passive
ServerActive=192.168.1.100 # آدرس سرور زبیکس برای ارسال‌های Active
Hostname=Linux-Server-01   # نام یکتا که باید دقیقاً در پنل وب تعریف شود

امنیت: استفاده از رمزنگاری PSK (Pre-Shared Key) برای ارتباط بین ایجنت و سرور در محیط‌های غیر ایزوله الزامی است. این کار مانع از شنود داده‌ها یا ارسال داده‌های جعلی توسط مهاجمین می‌شود.⁷

۴. کالبدشکافی و پیاده‌سازی اکوسیستم Prometheus

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

۴.۱. نصب و پیکربندی Node Exporter (چشم و گوش سیستم)

Node Exporter حیاتی‌ترین جزء برای مانیتورینگ سرور لینوکس در اکوسیستم پرومتئوس است. این ابزار متریک‌های سطح پایین سیستم‌عامل را استخراج کرده و اکسپوز می‌کند.

مراحل نصب امنیتی و سیستمی:

اجرای باینری‌ها به صورت مستقیم روشی ناامن است. باید کاربری مجزا و سرویس Systemd ایجاد شود.

۱. ایجاد کاربر ایزوله:

Bash

sudo useradd -rs /bin/false node_exporter

۲. دانلود و استقرار باینری:

Bash

wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar -xvzf node_exporter-1.8.0.linux-amd64.tar.gz
sudo mv node_exporter-1.8.0.linux-amd64/node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter

۳. تعریف سرویس Systemd (/etc/systemd/system/node_exporter.service):

Ini, TOML

[Unit]
Description=Node Exporter
After=network.target


User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter --collector.systemd --collector.processes

[Install]
WantedBy=multi-user.target

تحلیل فلگ‌ها: استفاده از --collector.systemd و --collector.processes برای دریافت اطلاعات وضعیت سرویس‌ها و پردازش‌ها ضروری است، زیرا به صورت پیش‌فرض ممکن است غیرفعال باشند.¹⁴

۴.۲. نصب و پیکربندی Prometheus Server

قلب تپنده سیستم که وظیفه Scraping و ذخیره داده‌ها را دارد.

۱. پیکربندی فایل prometheus.yml:

این فایل تعریف می‌کند که داده‌ها از کجا و هر چند وقت یکبار خوانده شوند.

YAML

global:
  scrape_interval: 15s     # فاصله زمانی استاندارد
  evaluation_interval: 15s # فاصله زمانی ارزیابی قوانین آلرت

scrape_configs:
  - job_name: 'node_exporter_clients'
    static_configs:
      - targets: ['192.168.1.50:9100', '192.168.1.51:9100']

در محیط‌های پویا به جای static_configs از مکانیسم‌های file_sd_configs یا kubernetes_sd_configs استفاده می‌شود تا لیست تارگت‌ها به صورت خودکار به‌روز شود.¹⁶

۲. سرویس Systemd برای Prometheus:

در فایل سرویس، مسیر دیتابیس و مدت زمان نگهداری داده‌ها (Retention) بسیار مهم است:

Bash

ExecStart=/usr/local/bin/prometheus \
  --config.file /etc/prometheus/prometheus.yml \
  --storage.tsdb.path /var/lib/prometheus/ \
  --storage.tsdb.retention.time 30d \
  --web.console.libraries=/etc/prometheus/console_libraries \
  --web.console.templates=/etc/prometheus/consoles

فلگ --storage.tsdb.retention.time 30d باعث می‌شود داده‌ها تا ۳۰ روز نگهداری شوند. پیش‌فرض ۱۵ روز است که اغلب ناکافی است.¹⁵

۵. استراتژی‌های پیشرفته مانیتورینگ منابع (Deep Dive Metrics)

این بخش مهم‌ترین قسمت گزارش برای متخصصان عملیاتی است. صرفاً جمع‌آوری داده کافی نیست؛ باید بدانیم کدام متریک‌ها واقعاً نشان‌دهنده سلامت سیستم هستند.

۵.۱. تحلیل پردازنده (CPU Analysis)

مانیتورینگ CPU تنها بررسی درصد استفاده نیست.

• در Zabbix:
  • آیتم system.cpu.util[,user]: نشان‌دهنده فشار ناشی از برنامه‌های کاربردی.
  • آیتم system.cpu.util[,iowait]: بسیار حیاتی. اگر این مقدار بالا باشد، مشکل از CPU نیست، بلکه دیسک گلوگاه شده است و CPU منتظر I/O مانده است.
  • آیتم system.cpu.load[percpu,avg1]: لود متوسط تقسیم بر تعداد هسته. اگر این عدد بالای ۱ باشد، یعنی صف پردازش طولانی شده است.¹⁹
• در Prometheus (PromQL):برای محاسبه دقیق مصرف CPU بدون در نظر گرفتن زمان بیکاری (Idle):Code snippet100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) تحلیل I/O Wait در پرومتئوس:Code snippetavg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) * 100 این کوئری‌ها با استفاده از تابع rate نرخ تغییرات را در ۵ دقیقه اخیر محاسبه می‌کنند که نویزهای لحظه‌ای را حذف می‌کند.³

۵.۲. تحلیل حافظه (Memory Analysis)

اشتباه رایج: تمرکز بر Free Memory. لینوکس حافظه خالی را برای Disk Cache استفاده می‌کند، بنابراین Free کم بودن لزوماً بد نیست.

• متریک طلایی: Available Memoryاین متریک نشان می‌دهد واقعاً چقدر حافظه برای اجرای برنامه‌های جدید در دسترس است (بدون استفاده از Swap).
  • PromQL:Code snippet(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 این فرمول درصد حافظه استفاده شده واقعی را محاسبه می‌کند.²¹
  • Zabbix: آیتم vm.memory.size[available] به طور مستقیم این مقدار را برمی‌گرداند.

۵.۳. تحلیل دیسک و ذخیره‌سازی (Storage)

در اینجا دو جنبه وجود دارد: فضا (Space) و عملکرد (Performance).

• فضا (Capacity Planning):استفاده از predict_linear در پرومتئوس می‌تواند زمان پر شدن دیسک را پیش‌بینی کند:Code snippetpredict_linear(node_filesystem_free_bytes[1h], 24 * 3600) < 0 این هشدار می‌دهد اگر با همین روند ادامه یابد، دیسک در ۲۴ ساعت آینده پر خواهد شد.²³
• عملکرد (Latency & IOPS):در Node Exporter، متریک‌های node_disk_io_time_seconds_total و node_disk_read_bytes_total کلیدی هستند. افزایش زمان سرویس‌دهی دیسک (Service Time) نشان‌دهنده خرابی قریب‌الوقوع یا اشباع دیسک است.

۵.۴. تحلیل شبکه (Network)

علاوه بر پهنای باند (node_network_receive_bytes_total)، باید خطاهای فیزیکی را پایش کرد. وجود errs یا drop در اینترفیس شبکه معمولاً نشانه مشکل کابل‌کشی، پورت سوییچ یا پر شدن بافر کارت شبکه است.

• PromQL:Code snippetrate(node_network_receive_errs_total[5m]) > 0 هر مقداری بالاتر از صفر نیازمند بررسی فوری است.³

۶. بصری‌سازی پیشرفته با Grafana

Grafana جایی است که داده‌ها تبدیل به دانش می‌شوند. قدرت گرافانا در ترکیب دیتاسورس‌هاست.

۶.۱. اتصال و پیکربندی Datasourceها

پس از نصب گرافانا (معمولاً پورت ۳۰۰۰)، اتصال پرومتئوس ساده است. اما برای اتصال Zabbix نیاز به نصب پلاگین است:

Bash

grafana-cli plugins install alexanderzobnin-zabbix-app
sudo systemctl restart grafana-server

سپس در تنظیمات پلاگین، آدرس API زبیکس (http://zabbix-server/zabbix/api_jsonrpc.php) وارد می‌شود. نکته مهم فعال‌سازی گزینه Trend است تا برای بازه‌های زمانی طولانی، گرافانا به جای History (داده‌های خام) از Trend (داده‌های میانگین ساعتی) استفاده کند که سرعت لود را به شدت افزایش می‌دهد.²⁵

۶.۲. داشبوردهای استاندارد صنعتی

ایجاد داشبورد از صفر زمان‌بر است. جامعه کاربری گرافانا داشبوردهای استانداردی بر اساس ID ارائه می‌دهد:

• Node Exporter Full (ID: 1860): کامل‌ترین داشبورد برای پرومتئوس. شامل گیج‌های دقیق CPU، نمودارهای حرارتی (Heatmap) برای توزیع بار، و جزئیات ریز دیسک.²⁷
• Zabbix Full Server Status (ID: 5363): یک داشبورد جامع برای نمایش داده‌های جمع‌آوری شده توسط ایجنت زبیکس.

نکته کاربردی: هنگام ایمپورت داشبورد 1860، حتماً دیتاسورس پرومتئوس خود را انتخاب کنید. این داشبورد از متغیرها (Variables) استفاده می‌کند که به شما اجازه می‌دهد بین سرورهای مختلف (Instances) به راحتی سوییچ کنید.²⁹

۷. نتیجه‌گیری و توصیه‌های استراتژیک

در پایان این بررسی عمیق، مشخص است که هیچ “بهترین ابزار مطلقی” وجود ندارد. انتخاب بین Zabbix و Prometheus باید بر اساس توپولوژی زیرساخت و مهارت تیم فنی انجام شود.

جدول تصمیم‌گیری نهایی:

توصیه نهایی: برای سازمان‌های بزرگ، رویکرد ترکیبی (Hybrid) بهترین گزینه است. استفاده از Zabbix برای زیرساخت فیزیکی و شبکه، و استفاده از Prometheus برای لایه اپلیکیشن و کانتینرها، و تجمیع تمام بصری‌سازی‌ها در Grafana، دیدی ۳۶۰ درجه و کامل را فراهم می‌کند. این معماری، نقاط کور را حذف کرده و قابلیت اطمینان سرویس‌ها را تضمین می‌کند.