مانیتورینگ سرور مهارتی حیاتی است که مرز بین یک سرویس پایدار و پرسرعت با یک سرویس ناپایدار و کند را تعیین می‌کند. بدون پایش مداوم منابع، شما در تاریکی حرکت می‌کنید و تنها زمانی از مشکل باخبر می‌شوید که کاربران شکایت کنند یا سایت از دسترس خارج شود. با مانیتورینگ درست، می‌توانید گلوگاه‌ها را پیش از بحرانی‌شدن شناسایی کنید، الگوهای مصرف را بفهمید و تصمیم‌های آگاهانه‌ای دربارهٔ ارتقای منابع بگیرید. در این راهنمای عملی، ابزارها و روش‌های شناسایی و رفع گلوگاه‌های چهار منبع اصلی سرور یعنی CPU، حافظه، دیسک و شبکه را بررسی می‌کنیم.
اصل بنیادین در مانیتورینگ سرور این است که هر گلوگاه در نهایت به یکی از این چهار منبع برمی‌گردد. وقتی سایت کند می‌شود، وظیفهٔ شما این است که تشخیص دهید کدام منبع اشباع شده است. یک اشتباه رایج این است که با دیدن کندی، بلافاصله رم یا CPU را افزایش می‌دهند، در حالی که ممکن است گلوگاه واقعی جای دیگری، مثلاً در I/O دیسک یا یک پروسهٔ خاص، باشد.
چهار منبع کلیدی در مانیتورینگ سرور
پیش از معرفی ابزارها، باید بدانیم دقیقاً چه چیزی را پایش می‌کنیم. در مانیتورینگ سرور، چهار منبع اصلی وجود دارد که هرکدام نشانه‌ها و ابزارهای تشخیص خاص خود را دارند.
| منبع | نشانهٔ اشباع | ابزار تشخیص |
|---|---|---|
| CPU | load average بالا، صف اجرا طولانی | htop، top، mpstat |
| حافظه (RAM) | swap شدید، OOM killer | free، vmstat |
| دیسک I/O | iowait بالا، تأخیر خواندن/نوشتن | iostat، iotop |
| شبکه | پهنای باند اشباع، پکت‌درپ | iftop، nload، ss |
شناخت این نشانه‌ها به شما اجازه می‌دهد به‌سرعت منبع مشکل‌ساز را محدود کنید. در ادامه هرکدام را با ابزار مناسب بررسی می‌کنیم.
پایش CPU و شناسایی گلوگاه پردازشی
اولین معیاری که باید بررسی کنید، بار سیستم یا load average است. این عدد نشان می‌دهد چند پروسه به‌طور میانگین منتظر اجرا هستند. با فرمان uptime به‌سرعت آن را می‌بینید:
uptime
# 14:32:01 up 40 days, 3:11, load average: 2.15, 1.98, 1.75سه عدد به‌ترتیب میانگین بار در یک، پنج و پانزده دقیقهٔ گذشته را نشان می‌دهند. قانون کلیدی این است که این اعداد را با تعداد هسته‌های CPU مقایسه کنید. اگر سرور شما ۴ هسته دارد و load average برابر ۴ است، یعنی CPU کاملاً مشغول اما بدون صف است. اگر بار به‌طور مداوم بالاتر از تعداد هسته‌ها باشد، CPU گلوگاه شماست.
شناسایی پروسهٔ پرمصرف
ابزار htop نمای زنده و رنگی‌ای از مصرف هر پروسه ارائه می‌دهد. برای دیدن پرمصرف‌ترین پروسه‌ها بر اساس CPU:
htop
# یا برای خروجی غیرتعاملی:
ps aux --sort=-%cpu | head -10اگر یک پروسهٔ خاص مثل php-fpm یا mysqld مداوم CPU را اشباع می‌کند، باید در سطح آن برنامه بهینه‌سازی کنید، نه صرفاً افزودن هسته. برای مثال CPU بالای MySQL معمولاً به کوئری‌های بهینه‌نشده اشاره دارد، نه کمبود پردازنده.
نکتهٔ مهم: مقدار iowait بالا در htop (بخش قرمز) نشانهٔ آن است که CPU در انتظار دیسک است، نه اینکه واقعاً مشغول محاسبه باشد. در این حالت، افزودن CPU کمکی نمی‌کند و باید به سراغ گلوگاه دیسک بروید.
پایش حافظه و مدیریت Swap
حافظهٔ رم منبع دیگری است که اشباع آن می‌تواند سرور را فلج کند. برای مشاهدهٔ وضعیت حافظه از فرمان free استفاده کنید:
free -h
# total used free shared buff/cache available
# Mem: 7.8Gi 4.2Gi 1.1Gi 256Mi 2.5Gi 3.1Gi
# Swap: 2.0Gi 0.5Gi 1.5Giستون کلیدی available است، نه free. لینوکس بخشی از رم را برای buff/cache استفاده می‌کند که در صورت نیاز آزاد می‌شود، پس free کم لزوماً بد نیست. اما اگر available به‌شدت پایین باشد و Swap در حال استفادهٔ فعال باشد، سرور با کمبود حافظه مواجه است.
خطر OOM Killer و Swap شدید
وقتی رم تمام شود، هستهٔ لینوکس یک مکانیزم به نام OOM Killer را فعال می‌کند که پروسه‌های پرمصرف را می‌کشد تا از فروپاشی کامل جلوگیری کند؛ این می‌تواند باعث از کار افتادن ناگهانی دیتابیس یا وب‌سرور شود. برای بررسی اینکه آیا OOM Killer فعال شده، لاگ سیستم را بررسی کنید:
dmesg | grep -i "killed process"
# یا:
journalctl -k | grep -i oomاستفادهٔ مداوم و شدید از Swap (به نام swap thrashing) عملکرد را به‌شدت کاهش می‌دهد چون دیسک صدها برابر کندتر از رم است. اگر vmstat نشان دهد ستون‌های si و so (swap in/out) مداوم بالا هستند، سرور به رم بیشتری نیاز دارد یا باید مصرف حافظهٔ برنامه‌ها را کاهش دهید.
vmstat 2 5پایش دیسک و رفع گلوگاه I/O
گلوگاه دیسک یکی از پنهان‌ترین و در عین حال رایج‌ترین مشکلات عملکرد است. معیار کلیدی iowait است که درصد زمانی را نشان می‌دهد که CPU بی‌کار مانده و منتظر تکمیل عملیات دیسک است. ابزار iostat جزئیات دقیقی ارائه می‌دهد:
iostat -x 2
# به ستون‌های %util و await دقت کنیدستون util% نشان می‌دهد دیسک چند درصد زمان مشغول بوده؛ نزدیک ۱۰۰ درصد یعنی دیسک اشباع است. ستون await میانگین زمان انتظار هر درخواست به میلی‌ثانیه است؛ برای دیسک SSD این عدد باید زیر چند میلی‌ثانیه و برای NVMe کسری از میلی‌ثانیه باشد. اعداد بالا نشانهٔ گلوگاه I/O است.
یافتن پروسهٔ پرمصرف دیسک
برای اینکه بفهمید کدام پروسه بیشترین I/O را ایجاد می‌کند، از iotop استفاده کنید:
sudo iotop -oPaراهکارهای رفع گلوگاه دیسک شامل مهاجرت از HDD به SSD یا NVMe، افزودن کش (تا خواندن‌ها به رم منتقل شود)، بهینه‌سازی کوئری‌های دیتابیس که نوشتن زیاد ایجاد می‌کنند، و انتقال لاگ‌های پرحجم به دیسک جداگانه است. در بسیاری از موارد، صرفاً فعال‌کردن کش آبجکت یا افزایش Buffer Pool دیتابیس، فشار خواندن از دیسک را به‌شدت کم می‌کند.
پایش شبکه و اتصالات
منبع چهارم، شبکه است. اگر پهنای باند اشباع شود یا تعداد اتصالات از حد بگذرد، سرور کند پاسخ می‌دهد. برای مشاهدهٔ زندهٔ مصرف پهنای باند از nload یا iftop استفاده کنید:
sudo iftop -i eth0
# مشاهده تعداد اتصالات فعال:
ss -sدستور ss خلاصه‌ای از اتصالات را نشان می‌دهد. تعداد بسیار بالای اتصالات در وضعیت TIME_WAIT می‌تواند نشانهٔ تنظیم نادرست کرنل یا حملهٔ احتمالی باشد. برای شمارش اتصالات به تفکیک وضعیت:
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rnتحلیل روند و ظرفیت‌سنجی
مانیتورینگ لحظه‌ای برای واکنش به بحران خوب است، اما ارزش واقعی مانیتورینگ در تحلیل روند (trend analysis) بلندمدت نهفته است. با نگاه به داده‌های چند هفته یا چند ماه، می‌توانید الگوهای رشد را ببینید و پیش از آنکه سرور به سقف برسد، برای ارتقا برنامه‌ریزی کنید. این کار ظرفیت‌سنجی (capacity planning) نام دارد.
برای مثال، اگر مشاهده کنید که میانگین مصرف رم هر ماه ۵ درصد افزایش می‌یابد، می‌توانید تخمین بزنید چند ماه دیگر به ارتقای رم نیاز خواهید داشت. همین‌طور، شناسایی الگوهای دوره‌ای مثل اوج ترافیک در ساعات یا روزهای خاص، به شما کمک می‌کند کارهای سنگین مثل پشتیبان‌گیری یا بهینه‌سازی جداول را در ساعات کم‌ترافیک زمان‌بندی کنید.
تفکیک نشانه از علت
یکی از مهارت‌های کلیدی در رفع گلوگاه، تفکیک نشانه از علت ریشه‌ای است. مصرف بالای CPU یک نشانه است، نه علت. علت ممکن است یک کوئری بد، یک حلقهٔ بی‌پایان در کد، یا حملهٔ ترافیکی باشد. رویکرد درست این است که از نشانه به سمت علت حرکت کنید:
- ابتدا منبع اشباع‌شده را شناسایی کنید (CPU، رم، دیسک یا شبکه).
- سپس پروسهٔ مسئول آن مصرف را پیدا کنید.
- در نهایت بفهمید چرا آن پروسه این‌قدر منبع مصرف می‌کند.
برای نمونه، اگر iowait بالا دیدید، پروسهٔ پرمصرف دیسک را با iotop می‌یابید، و اگر آن پروسه mysqld بود، به سراغ لاگ کوئری کند می‌روید تا کوئری مقصر را پیدا کنید. این زنجیرهٔ منطقی از حدس‌زدن جلوگیری می‌کند و شما را مستقیم به راه‌حل می‌رساند.
نکتهٔ عملی: همیشه پیش از اعمال تغییر بزرگ، وضعیت پایه (baseline) را ثبت کنید. بدون دانستن رفتار عادی سرور، نمی‌توانید تشخیص دهید که یک عدد غیرعادی است یا طبیعی. مثلاً load average برابر ۳ برای یک سرور ممکن است عادی و برای دیگری هشداردهنده باشد.
راه‌اندازی مانیتورینگ مداوم و هشدار
ابزارهای خط فرمان برای بررسی لحظه‌ای عالی‌اند، اما برای پایش بلندمدت به سیستم مانیتورینگ مداوم نیاز دارید که داده را در طول زمان ذخیره کند و در صورت عبور از آستانه هشدار بفرستد. چند رویکرد رایج:
- Netdata: نصب سریع و داشبورد زندهٔ بسیار دقیق با نمودارهای هر ثانیه؛ برای شروع سریع عالی است.
- Prometheus + Grafana: استاندارد صنعتی برای جمع‌آوری متریک و ساخت داشبورد و هشدار حرفه‌ای؛ مناسب محیط‌های بزرگ‌تر.
- Monit یا Uptime Kuma: برای پایش در دسترس‌بودن سرویس‌ها و ری‌استارت خودکار در صورت خرابی.
نصب Netdata تنها یک فرمان است و بلافاصله داشبورد کاملی در اختیار شما می‌گذارد:
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.shمهم‌ترین بخش، تنظیم هشدار (alert) است. باید آستانه‌هایی تعیین کنید که پیش از بحرانی‌شدن به شما اطلاع دهند؛ مثلاً هشدار وقتی مصرف دیسک از ۸۰ درصد گذشت، یا وقتی load average بیش از دو برابر تعداد هسته‌ها شد. هشدار زودهنگام به شما فرصت می‌دهد پیش از قطعی سرویس اقدام کنید.
پس از شناسایی گلوگاه پایدار، گاهی راه‌حل واقعاً ارتقای منابع است. اگر پایش نشان دهد سرور به‌طور مداوم به سقف CPU یا رم می‌رسد، زمان آن است که به پلن قوی‌تری مهاجرت کنید؛ می‌توانید برای خرید سرور مجازی با منابع بیشتر و قابلیت ارتقای آسان اقدام کنید و راهنماهای تکمیلی را در مقالات رپیدو سرور دنبال کنید.
پایش لاگ‌ها و رویدادها
مانیتورینگ منابع تنها نیمی از ماجراست؛ نیمهٔ دیگر، پایش لاگ‌های سیستم و برنامه است. بسیاری از مشکلات پیش از آنکه در نمودار منابع ظاهر شوند، ابتدا در لاگ‌ها نشانه می‌دهند. برای مثال، افزایش ناگهانی خطاهای ۵۰۰ در لاگ Nginx می‌تواند اولین نشانهٔ یک مشکل بک‌اند باشد. با دستور tail می‌توانید لاگ‌ها را به‌صورت زنده دنبال کنید:
tail -f /var/log/nginx/error.log
# شمارش کدهای وضعیت در لاگ دسترسی:
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rnاین فرمان توزیع کدهای وضعیت HTTP را نشان می‌دهد. اگر تعداد خطاهای ۴۰۴ یا ۵۰۰ به‌طور غیرعادی بالا باشد، باید بررسی کنید. برای محیط‌های بزرگ‌تر، ابزارهای متمرکزسازی لاگ مثل Loki یا استک ELK امکان جستجو و هشدار روی لاگ‌های چند سرور را فراهم می‌کنند و تصویر یکپارچه‌ای از سلامت کل سیستم می‌دهند.
خودکارسازی واکنش به مشکلات
در نهایت، بلوغ مانیتورینگ زمانی است که بتوانید به برخی مشکلات به‌صورت خودکار واکنش نشان دهید. برای مثال، اگر یک سرویس از کار افتاد، ابزارهایی مثل systemd با گزینهٔ Restart=on-failure می‌توانند آن را به‌صورت خودکار مجدداً راه‌اندازی کنند. یا اگر دیسک به آستانهٔ خطرناک رسید، یک اسکریپت خودکار می‌تواند لاگ‌های قدیمی را پاک‌سازی کند. این خودکارسازی، فشار عملیاتی را کاهش می‌دهد و از قطعی‌های شبانه جلوگیری می‌کند.
در جمع‌بندی، مانیتورینگ سرور یک فعالیت پیوسته است، نه واکنش به بحران. با شناخت چهار منبع کلیدی، تسلط بر ابزارهای تشخیص، پایش لاگ‌ها و راه‌اندازی سیستم هشدار مداوم، می‌توانید مشکلات را پیش از تأثیرگذاری بر کاربران شناسایی و رفع کنید و سرویسی پایدار و پرسرعت ارائه دهید.
سوالات متداول
load average چه عددی خطرناک محسوب می‌شود؟
این عدد باید نسبت به تعداد هسته‌های CPU سنجیده شود. اگر سرور ۴ هسته دارد، load average حدود ۴ یعنی استفادهٔ کامل بدون صف. اعداد به‌طور مداوم بالاتر از تعداد هسته‌ها (مثلاً ۸ روی سرور ۴ هسته‌ای) نشانهٔ گلوگاه پردازشی و صف انتظار است که باعث کندی می‌شود.
تفاوت free و available در دستور free چیست؟
free مقدار رمی است که اصلاً استفاده نمی‌شود، اما available مقدار رمی است که واقعاً برای برنامه‌های جدید قابل استفاده است، شامل حافظهٔ کش که در صورت نیاز آزاد می‌شود. همیشه به available توجه کنید؛ free کم به‌تنهایی نگران‌کننده نیست چون لینوکس عمداً از رم آزاد برای کش استفاده می‌کند.
iowait بالا یعنی چه و چطور رفعش کنم؟
iowait بالا یعنی CPU بیشتر وقت خود را در انتظار پاسخ دیسک می‌گذراند، که نشانهٔ گلوگاه I/O است. راه‌حل‌ها شامل مهاجرت به دیسک SSD یا NVMe، افزودن کش برای کاهش خواندن از دیسک، و بهینه‌سازی کوئری‌های دیتابیس پرنوشتن است. افزودن CPU در این حالت کمکی نمی‌کند.
بهترین ابزار برای شروع مانیتورینگ کدام است؟
برای شروع سریع، Netdata بهترین گزینه است چون با یک فرمان نصب می‌شود و بلافاصله داشبورد زنده و دقیقی ارائه می‌دهد. برای محیط‌های بزرگ‌تر که به نگهداری تاریخچهٔ بلندمدت و هشدارهای پیشرفته نیاز دارند، ترکیب Prometheus و Grafana استاندارد صنعتی است.
