در بیشتر شرکت ها اولین خبر از مشکل سرور، تلفن یک کاربر است: «سیستم باز نمی شود». تا آن لحظه دیسک پر شده، دیتابیس متوقف شده یا گواهی SSL منقضی شده و هیچ کس متوجه نبوده است. مانیتورینگ سرور این ترتیب را برعکس می کند تا اول شما خبردار شوید. پایین تر می خوانید مانیتورینگ سرور چیست و چه چیزهایی را باید زیر نظر گرفت. بعد به فرق ابزارهای رایجی مثل Zabbix و Prometheus می رسیم و اینکه هشدار را چطور تنظیم کنید که نادیده گرفته نشود.
مانیتورینگ سرور چیست؟
مانیتورینگ سرور یعنی جمع آوری منظم و خودکار داده از سرورها و سرویس ها، نگهداری سابقه آن و ارسال هشدار وقتی یک مقدار از حد مجاز عبور می کند. این داده می تواند مصرف پردازنده و حافظه باشد، فضای دیسک، وضعیت یک سرویس، زمان پاسخ یک صفحه وب یا تعداد خطاهای یک اپلیکیشن.
از مانیتورینگ دو چیز می خواهیم. یکی هشدار در لحظه، تا وقتی چیزی خراب شده یا دارد خراب می شود کسی باخبر شود. دیگری سابقه و روند: وقتی سرور کند شده، نمودار دو هفته گذشته را باز می کنید و می بینید از کی و چرا. بدون این سابقه، رفع مشکل به حدس و گمان می رسد.
تفاوت مانیتورینگ آپتایم با مانیتورینگ کامل سرور
بررسی آپتایم فقط می گوید سایت یا پورت در دسترس هست یا نه. به آن نیاز دارید، اما معمولا وقتی خبر می دهد که قطعی اتفاق افتاده است. مانیتورینگ کامل سرور علامت های قبل از قطعی را هم می بیند: دیسکی که هر روز یک درصد پرتر می شود، حافظه ای که آرام آرام به swap می رود یا صف ایمیلی که مدام بزرگ تر می شود.
چه چیزی را مانیتور کنیم؟
جدول زیر نقطه شروع است. آستانه ها فقط پیشنهادند؛ بعد از اینکه چند هفته رفتار واقعی سرور خودتان را دیدید، آن ها را تنظیم کنید.
| لایه | شاخص | چرا مهم است | آستانه اولیه پیشنهادی |
|---|---|---|---|
| پردازنده | درصد مصرف، load average، iowait | iowait بالا معمولا نشانه گلوگاه دیسک است | مصرف بالای 90 درصد به مدت چند دقیقه |
| حافظه | حافظه در دسترس، مصرف swap | شروع swap یعنی کندی محسوس سرویس ها | حافظه در دسترس کمتر از 10 درصد |
| دیسک | فضای آزاد، inode، latency | دیسک پر دیتابیس و لاگ را متوقف می کند | فضای آزاد کمتر از 15 درصد |
| سلامت سخت افزار | SMART، وضعیت RAID، دما، منبع تغذیه | خرابی دیسک در RAID تا دیسک دوم دیده نمی شود | هر تغییر وضعیت از OK |
| شبکه | ترافیک، خطای اینترفیس، packet loss | مشکل کابل یا سوئیچ اول به شکل خطا دیده می شود | افزایش خطا یا loss پایدار |
| سرویس ها | وضعیت Nginx، MySQL، سرویس ایمیل، AD | سرور روشن است ولی سرویس از کار افتاده | توقف سرویس |
| اپلیکیشن | زمان پاسخ، کد خطای HTTP، کوئری های کند | تجربه کاربر را مستقیم نشان می دهد | افزایش خطای 5xx |
| امنیت و انقضا | تاریخ انقضای SSL و دامنه، تلاش ورود ناموفق | انقضای گواهی قطعی کامل ایجاد می کند | کمتر از 14 روز به انقضا |
| بکاپ | موفقیت آخرین بکاپ و زمان آن | بکاپ متوقف شده تا روز حادثه دیده نمی شود | عدم موفقیت یا گذشتن بیش از یک دوره |
مانیتورینگ سرور لینوکس با دستورهای پایه
پیش از نصب هر ابزاری، این دستورها تصویر سریعی از وضعیت سرور لینوکس می دهند. ابزارهای مانیتورینگ هم همین داده ها را جمع می کنند، فقط به صورت خودکار:
uptime # load average یک، پنج و پانزده دقیقه
vmstat 1 5 # CPU، swap و iowait در پنج ثانیه
iostat -x 1 3 # latency و درصد مشغولی دیسک ها (بسته sysstat)
free -m # حافظه در دسترس
df -h && df -i # فضای دیسک و inode
systemctl --failed # سرویس های متوقف شده
journalctl -p err -b # خطاهای ثبت شده از آخرین بوتمانیتورینگ ویندوز سرور
در ویندوز همین داده ها از Performance Counter ها خوانده می شوند. برای یک بررسی سریع در PowerShell:
Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes','\LogicalDisk(*)\% Free Space' -SampleInterval 5 -MaxSamples 3روی ویندوز سرور معمولا Event Log را هم پایش می کنند؛ مثلا خطاهای سرویس Active Directory، هشدارهای دیسک و شکست Windows Backup.
مانیتورینگ اتاق سرور و دمای آن
مانیتورینگ اتاق سرور معمولا فراموش می شود، با اینکه خرابی کولر یا قطعی برق می تواند همه سرورها را با هم از کار بیندازد. دمای داخلی سرورها از طریق IPMI یا کارت مدیریت (iDRAC در Dell و iLO در HPE) قابل خواندن است. UPS ها معمولا کارت شبکه با SNMP دارند که وضعیت باتری و قطعی برق را گزارش می کند. دما و رطوبت خود اتاق را هم می شود با سنسورهای شبکه ای که SNMP دارند خواند.
ابزار مانیتورینگ سرور: کدام را انتخاب کنیم؟
| ابزار | مناسب برای | نکته |
|---|---|---|
| Zabbix | شبکه و سرورهای متنوع سازمانی، تجهیزات SNMP | متن باز، رابط وب کامل، قالب های آماده زیاد |
| Prometheus و Grafana | سرورهای لینوکسی، کانتینر و Kubernetes، متریک های اپلیکیشن | پیکربندی با فایل، انعطاف زیاد، نیاز به دانش بیشتر |
| Uptime Kuma | بررسی آپتایم سایت، پورت و گواهی SSL | نصب ساده، مناسب کنار یک سیستم کامل تر |
| PRTG | محیط های ویندوزی که ابزار تجاری با راه اندازی سریع می خواهند | لایسنس بر اساس تعداد سنسور |
| LibreNMS | مانیتورینگ سوئیچ و روتر با SNMP | کشف خودکار تجهیزات شبکه |
| Netdata | دید لحظه ای و دقیق روی یک یا چند سرور | نصب سریع، نمودارهای ثانیه ای |
zabbix چیست؟
Zabbix یک سیستم مانیتورینگ متن باز است که سرورها، ماشین های مجازی، تجهیزات شبکه، دیتابیس ها و سرویس ها را از یک کنسول وب پایش می کند. اجزای اصلی آن Zabbix Server، یک دیتابیس (MySQL/MariaDB یا PostgreSQL)، رابط وب و در صورت نیاز Zabbix Proxy برای شعبه ها یا شبکه های جدا هستند. داده با agent، SNMP، IPMI، بررسی HTTP و روش های دیگر جمع می شود. منطق هشدار با trigger تعریف می شود؛ مثلا این عبارت وقتی میانگین مصرف CPU در پنج دقیقه از 90 درصد بالاتر برود فعال می شود:
avg(/web-01/system.cpu.util,5m)>90در محیط عملیاتی سراغ نسخه های LTS بروید و پیش از نصب، نسخه LTS فعلی و سازگاری آن با توزیع لینوکس خودتان را در سایت Zabbix چک کنید.
zabbix agent چیست؟
Zabbix Agent برنامه کوچکی است که روی سرور مقصد نصب می شود و داده های محلی مثل CPU، حافظه، دیسک، سرویس ها و لاگ ها را جمع می کند. نسخه جدیدتر آن Zabbix Agent 2 است که با Go نوشته شده و پلاگین هایی برای سرویس هایی مثل MySQL، PostgreSQL و Docker دارد. agent در دو حالت کار می کند: در حالت passive سرور روی پورت 10050 از agent داده می خواهد و در حالت active خود agent داده را به پورت 10051 سرور می فرستد. حالت active برای سرورهای پشت NAT مناسب تر است. تنظیمات اصلی در فایل agent این سه خط است:
# /etc/zabbix/zabbix_agent2.conf
# سروری که اجازه درخواست passive دارد
Server=10.0.0.5
# سرور یا پراکسی برای ارسال active
ServerActive=10.0.0.5
# باید دقیقا با نام میزبان در رابط وب یکی باشد
Hostname=web-01در فایل های تنظیم Zabbix توضیح باید در خط جدا نوشته شود و بعد از مقدار قابل استفاده نیست.
روی فایروال سرور مقصد، پورت 10050 را فقط برای آدرس Zabbix Server یا Proxy باز کنید.
Prometheus و Grafana
Prometheus در بازه های مشخص از endpoint های HTTP متریک می خواند (مدل pull) و آن ها را در دیتابیس سری زمانی خودش نگه می دارد. روی سرورهای لینوکس، node_exporter متریک های سیستم عامل را روی پورت 9100 منتشر می کند. Grafana برای داشبورد استفاده می شود و Alertmanager مسئول گروه بندی و ارسال هشدارهاست. یک نمونه ساده از تنظیم scrape و یک قانون هشدار برای پر شدن دیسک:
# prometheus.yml
scrape_configs:
- job_name: node
static_configs:
- targets: ['10.0.0.11:9100', '10.0.0.12:9100']
# rules/node.yml
groups:
- name: node
rules:
- alert: DiskAlmostFull
expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} < 0.15
for: 15m
labels:
severity: warning
annotations:
summary: "فضای دیسک {{ $labels.instance }} کمتر از 15 درصد است"وقتی نیازتان بیشتر داشبورد، لاگ مرکزی و متریک های اپلیکیشن باشد، کار به حوزه Observability می رسد که Grafana، Prometheus و لاگ مرکزی را کنار هم می گذارد.
مانیتورینگ از بیرون شبکه
سیستم مانیتورینگی که داخل همان دیتاسنتر است، قطعی کل دیتاسنتر یا اینترنت آن را نمی بیند. این نقطه کور را یک بررسی ساده آپتایم از بیرون می پوشاند، مثلا Uptime Kuma روی سروری در یک دیتاسنتر دیگر. با توجه به اختلال های گاه و بی گاه ارتباط بین الملل، اگر کاربران شما داخل ایران هستند، دست کم یکی از نقاط بررسی هم داخل کشور باشد.
هشداردهی: هشداری بسازید که دیده شود
در عمل، بزرگ ترین مشکل مانیتورینگ انبوه هشدارهایی است که کسی نگاهشان نمی کند. وقتی روزی ده ها پیام بی اهمیت می رسد، پیام مهم هم لابه لای آن ها گم می شود. چند قاعده که جلوی این وضع را می گیرد:
- دست کم دو سطح هشدار داشته باشید. «بحرانی» یعنی کسی همین حالا باید کاری کند و «هشدار» یعنی در ساعت کاری بررسی شود.
- برای هر شرط مدت پایداری تعیین کنید (مثل
for: 15mدر Prometheus)، چون یک لحظه مصرف بالای CPU مشکل نیست. - هر هشدار باید یک صاحب داشته باشد. وقتی همه هشدارها به یک گروه بزرگ فرستاده می شود، عملا کسی مسئولش نیست.
- ایمیل برای هشدارهای عادی کافی است و پیامک یا پیام رسان برای بحرانی ها. کانال هایی را انتخاب کنید که در زمان اختلال اینترنت هم کار کنند.
- هنگام به روزرسانی یا ریبوت برنامه ریزی شده، هشدارها را موقتا ساکت کنید (maintenance در Zabbix یا silence در Alertmanager).
- خود سیستم مانیتورینگ را هم پایش کنید. اگر سرور Zabbix یا Prometheus از کار بیفتد هیچ هشداری نمی رسد، پس یک بررسی مستقل برایش تعریف کنید.
- هر ماه هشدارها را مرور کنید؛ هشداری که همیشه نادیده گرفته می شود یا باید اصلاح شود یا حذف.
چک لیست راه اندازی مانیتورینگ سرور
- فهرست سرورها، سرویس ها و تجهیزات شبکه را با اولویت هر کدام بنویسید.
- ابزار را بر اساس محیط انتخاب کنید: تنوع تجهیزات و SNMP به سمت Zabbix، کانتینر و متریک اپلیکیشن به سمت Prometheus.
- سرور مانیتورینگ را جدا از سرورهای اصلی و با بکاپ مخصوص خودش راه اندازی کنید.
- agent یا exporter را نصب کنید و پورت آن را در فایروال فقط برای سرور مانیتورینگ باز کنید.
- شاخص های پایه جدول بالا را فعال کنید و چند هفته داده جمع کنید.
- آستانه ها را بر اساس رفتار واقعی تنظیم و هشدارها را سطح بندی کنید.
- یک بررسی آپتایم از بیرون شبکه اضافه کنید.
- مسیر هشدار را با یک خطای ساختگی تست کنید، مثلا متوقف کردن یک سرویس آزمایشی.
- برای هر هشدار بحرانی، یک راهنمای کوتاه بنویسید: چه چیزی را بررسی کنیم و چه کسی را خبر کنیم.
اگر با Zabbix راحت نیستید، ترکیب Prometheus و Grafana راه دیگری است و در نصب Grafana و Prometheus قدم به قدم آمده. مانیتورینگ زمانی ارزش دارد که هشدارها به تعهدی مثل SLA وصل باشند؛ این رابطه در SLA چیست توضیح داده شده است.
راه اندازی داخلی یا سپردن مانیتورینگ به تیم بیرونی؟
نصب Zabbix یا Prometheus چند ساعت کار است. وقت اصلی صرف تنظیم آستانه ها، نگهداری قالب ها و به روزرسانی خود سیستم مانیتورینگ می شود، و از همه سخت تر، جواب دادن به هشدار در ساعت غیرکاری. در تیم IT یک یا دو نفره، معمولا همین آخری مشکل ساز می شود. در سرویس مانیتورینگ پیشگیرانه سرور و شبکه، مانیتورینگ روی زیرساخت خودتان راه اندازی می شود و هشدارها به تیم ما می رسد تا بررسی شوند. گزارش دوره ای هم برایتان می فرستیم. دامنه کار و زمان پاسخ را قرارداد تعیین می کند.
جمع آوری و تحلیل متمرکز لاگ ها در SIEM چیست توضیح داده شده است.
منابع و مستندات رسمی
هزینه پایش و پشتیبانی دائمی بسته به دامنه کار متفاوت است؛ عوامل آن در تعرفه خدمات پشتیبانی شبکه آمده است.
اگر فعلا فقط می خواهید بدانید سایت و سرورتان قطع می شوند یا نه، می توانید با مانیتورینگ رایگان آپتایم شروع کنید. برای صحبت درباره شاخص ها و ابزار مناسب محیط خودتان هم از صفحه مانیتورینگ شبکه و سرور با ما در تماس باشید.
