بیشتر قطعی‌های سرور ناگهانی نیستند: دیسکی که آرام‌آرام پر می‌شود، حافظه‌ای که هر روز کمی بیشتر مصرف می‌شود یا گواهی SSL که فردا منقضی می‌شود. مانیتورینگ سرور یعنی این نشانه‌ها را پیش از تبدیل شدن به قطعی ببینید و وقتی مشکلی رخ داد، اولین نفری باشید که خبردار می‌شود، نه مشتریانتان. در این مقاله توضیح می‌دهیم مانیتورینگ چیست، چه چیزهایی را باید پایش کرد، هشدار درست چطور تعریف می‌شود و چه ابزارهایی برای شروع مناسب‌اند.
فهرست مطالب
مانیتورینگ سرور چیست؟
مانیتورینگ یعنی جمع‌آوری مداوم اطلاعات درباره سلامت و کارایی سرورها و سرویس‌ها، نگهداری تاریخچه آن‌ها و ارسال هشدار وقتی چیزی از حالت عادی خارج می‌شود. مانیتورینگ خوب سه سوال را پاسخ می‌دهد:
- آیا سرویس الان کار می‌کند؟ (دسترس‌پذیری)
- آیا خوب کار می‌کند؟ (کارایی: زمان پاسخ، خطاها)
- آیا به‌زودی مشکل خواهد داشت؟ (روندها: رشد مصرف دیسک، حافظه یا ترافیک)
سه نوع داده: معیارها، لاگ‌ها و بررسی از بیرون
- معیارها (Metrics): اعدادی که در فواصل منظم ثبت می‌شوند؛ مثل درصد CPU، RAM آزاد، فضای دیسک و ترافیک شبکه. برای نمودار و تشخیص روند عالی‌اند.
- لاگ‌ها (Logs): رویدادهای ثبت‌شده توسط سیستم و برنامه‌ها؛ مثل خطاهای وب‌سرور، ورودهای SSH یا خطاهای دیتابیس. برای فهمیدن «چرا» یک مشکل رخ داده لازم‌اند.
- بررسی از بیرون (Synthetic / Uptime): یک سرویس خارجی هر چند ثانیه سایت یا پورت را مثل یک کاربر واقعی بررسی می‌کند. حتی اگر خود سرور خاموش باشد، این بررسی قطعی را تشخیص می‌دهد.
یک برنامه مانیتورینگ کامل هر سه را دارد؛ اما برای شروع، بررسی از بیرون و معیارهای پایه بیشترین ارزش را با کمترین زحمت دارند.
چه چیزهایی را پایش کنیم؟
| لایه | مواردی برای پایش |
|---|---|
| دسترس‌پذیری | پاسخ HTTP سایت (کد ۲۰۰ و وجود یک متن مشخص در صفحه)، پورت‌های مهم، پینگ |
| منابع سرور | CPU، بار سیستم (Load)، RAM و Swap، فضای دیسک و inode، I/O Wait |
| شبکه | ترافیک ورودی و خروجی، از دست رفتن بسته، تعداد اتصال‌ها |
| سرویس‌ها | وضعیت وب‌سرور، PHP-FPM، دیتابیس، Redis، صف‌ها و Workerها |
| اپلیکیشن | زمان پاسخ، نرخ خطاهای 5xx، کوئری‌های کند، طول صف |
| امنیت و نگهداری | انقضای SSL و دامنه، ورودهای SSH، اجرای موفق بکاپ، به‌روزرسانی‌های امنیتی |
دو مورد پایانی اغلب فراموش می‌شوند: منقضی شدن گواهی SSL یا دامنه و بکاپی که هفته‌هاست بی‌صدا شکست خورده، از رایج‌ترین علت‌های بحران‌های قابل پیشگیری‌اند. اصول بکاپ را در بکاپ سرور چیست ببینید.
هشدار درست چطور تعریف می‌شود؟
هشدار بد از نداشتن هشدار بدتر است: وقتی هر روز ده‌ها هشدار بی‌اهمیت می‌رسد، تیم به آن‌ها عادت می‌کند و هشدار واقعی هم نادیده گرفته می‌شود. اصول هشدار خوب:
- روی علامت‌های اثرگذار بر کاربر هشدار دهید: «سایت پاسخ نمی‌دهد» یا «نرخ خطا بالا رفته»، نه «CPU برای ۳۰ ثانیه به ۹۰ درصد رسید».
- مدت زمان را در نظر بگیرید: هشدار فقط وقتی شرایط چند دقیقه ادامه دارد، تا جهش‌های لحظه‌ای هشدار تولید نکنند.
- هشدار پیش‌دستانه برای روندها: «دیسک با این روند تا ۳ روز دیگر پر می‌شود» از «دیسک ۹۵ درصد پر است» مفیدتر است.
- سطح‌بندی: فوری (تماس یا پیامک)، مهم (تلگرام) و اطلاعاتی (ایمیل یا گزارش روزانه).
- هر هشدار یک اقدام مشخص: اگر برای هشداری کاری نمی‌کنید، آن را حذف یا تبدیل به گزارش کنید.
ابزارهای رایج
| ابزار | نوع | مناسب برای |
|---|---|---|
| Uptime Kuma | بررسی دسترس‌پذیری و صفحه وضعیت | شروع سریع، کسب‌وکارهای کوچک |
| Zabbix | مانیتورینگ کامل زیرساخت با Agent | چند سرور تا زیرساخت سازمانی |
| Prometheus و Grafana | معیارها و داشبورد | محیط‌های Docker و Kubernetes و تیم‌های فنی |
| Netdata | پایش لحظه‌ای با جزئیات زیاد | عیب‌یابی سریع یک سرور |
| Loki یا ELK | جمع‌آوری متمرکز لاگ | بررسی حادثه و تحلیل لاگ |
آموزش راه‌اندازی دو ابزار پرکاربرد: Uptime Kuma و Zabbix. برای نمودار ترافیک ماهانه هم گراف ترافیک ماهانه سرور را ببینید.
نکته مهم: سرور مانیتورینگ را روی همان سروری که پایش می‌کنید قرار ندهید؛ اگر آن سرور از کار بیفتد، مانیتورینگ هم همراهش خاموش می‌شود و هشداری ارسال نمی‌شود.
شروع ساده در سه قدم
- بررسی از بیرون: برای سایت، پورت‌های اصلی و انقضای SSL یک مانیتور با هشدار تلگرامی یا پیامکی بسازید. این قدم به‌تنهایی بیشتر قطعی‌ها را در چند دقیقه به اطلاع شما می‌رساند.
- معیارهای پایه سرور: CPU، RAM، دیسک و ترافیک را با یک Agent جمع‌آوری کنید و برای پر شدن دیسک و کمبود حافظه هشدار تعریف کنید.
- لاگ و اپلیکیشن: وقتی دو قدم اول پایدار شد، نرخ خطاهای وب‌سرور، کوئری‌های کند و اجرای بکاپ را اضافه کنید.
اشتباه‌های رایج
- مانیتورینگ روی همان سرور اصلی.
- هشدارهای زیاد و بی‌اهمیت که باعث نادیده گرفتن هشدارهای واقعی می‌شوند.
- هشدار فقط به ایمیلی که کسی آن را نمی‌خواند.
- پایش «پینگ» به‌جای پایش «کار کردن سایت»؛ سرور ممکن است پینگ بدهد اما سایت خطای ۵۰۰ برگرداند.
- نداشتن تاریخچه؛ بدون نمودار هفته‌ها و ماه‌ها، تشخیص روند و برنامه‌ریزی ارتقا ممکن نیست.
سوالات متداول
برای یک سایت کوچک هم مانیتورینگ لازم است؟
بله، حداقل بررسی دسترس‌پذیری و انقضای SSL. راه‌اندازی آن چند دقیقه طول می‌کشد و جلوی ساعت‌ها قطعی بی‌خبر را می‌گیرد.
هر چند وقت یک بار سایت باید بررسی شود؟
برای اغلب سایت‌ها هر ۳۰ تا ۶۰ ثانیه کافی است. هشدار را پس از دو یا سه شکست متوالی ارسال کنید تا خطاهای لحظه‌ای هشدار کاذب نسازند.
تفاوت مانیتورینگ و Observability چیست؟
مانیتورینگ به سوال‌های از پیش تعیین‌شده پاسخ می‌دهد (آیا سایت بالاست؟). Observability یعنی داده‌های کافی (معیار، لاگ و Trace) برای پاسخ به سوال‌هایی که از قبل نمی‌دانستید؛ برای سیستم‌های پیچیده اهمیت پیدا می‌کند.
بهترین ابزار مانیتورینگ کدام است؟
برای شروع Uptime Kuma، برای زیرساخت چندسروری Zabbix و برای تیم‌های DevOps با Docker، Prometheus و Grafana. ابزاری را انتخاب کنید که تیم شما واقعاً نگهداری‌اش کند.
مانیتورینگ ۲۴ ساعته بدون دردسر راه‌اندازی
با خدمات مانیتورینگ تراست هاست، منابع سرور، دیسک، سرویس‌های وب و پورت‌ها پایش می‌شوند و هشدارها از طریق پیامک، ایمیل و تلگرام ارسال می‌شود.
