دستورات مانیتورینگ سرور لینوکس برای بررسی سلامت سرور

دستورات مانیتورینگ سرور لینوکس برای یک بررسی سلامت سریع این‌ها هستند: uptime برای بار سیستم، top یا htop برای پردازه‌های پرمصرف، vmstat و free برای حافظه و swap، df برای فضای دیسک و inode، iostat برای کندی دیسک، ss برای اتصالات شبکه و journalctl برای خطاهای اخیر. خروجی خام این دستورها به‌تنها چیزی نمی‌گوید؛ در هر بخش آمده که کدام ستون نشانه مشکل است و قدم بعدی چیست.

همه دستورها فقط‌خواندنی هستند و روی سرور در حال سرویس‌دهی قابل اجرا هستند. top، free و df را احتمالاً از دستورات پایه لینوکس می‌شناسید؛ این راهنما روی تفسیر خروجی و ترتیب بررسی تمرکز دارد. مفاهیم مانیتورینگ مداوم و انتخاب ابزار را در راهنمای مانیتورینگ سرور ببینید. مثال‌ها روی Ubuntu، Debian و خانواده RHEL (Rocky Linux و AlmaLinux) قابل اجرا هستند.

ترتیب اجرای دستورات مانیتورینگ سرور لینوکس

وقتی گزارش «سرور کند شده» می‌رسد، بررسی را از کلی به جزئی پیش ببرید. جدول زیر ترتیبی است که بخش‌های بعدی با جزئیات توضیح می‌دهند:

uptime و load average: سرور چقدر زیر بار است؟

uptime
nproc
cat /proc/loadavg

سه عدد load average میانگین بار در ۱، ۵ و ۱۵ دقیقه اخیر است. در لینوکس این عدد هم پردازه‌هایی را که منتظر CPU هستند می‌شمارد و هم پردازه‌هایی را که در انتظار I/O دیسک مانده‌اند؛ پس load بالا همیشه به معنی پر بودن CPU نیست و ممکن است از کندی دیسک یا استوریج شبکه باشد.

عدد را با خروجی nproc مقایسه کنید. load برابر ۸ روی سرور ۸ هسته‌ای یعنی همه هسته‌ها مشغول‌اند، اما همین عدد روی سرور ۲ هسته‌ای یعنی صف انتظار طولانی. اگر عدد یک‌دقیقه‌ای خیلی بیشتر از عدد پانزده‌دقیقه‌ای است، مشکل تازه شروع شده و هنوز می‌توانید پردازه مسئول را در حال اجرا ببینید.

top و htop: کدام پردازه منابع را مصرف می‌کند؟

top
top -b -n 1 -o %MEM | head -20     # one snapshot sorted by memory

# htop: Debian / Ubuntu
sudo apt install htop
# htop: RHEL / Rocky / AlmaLinux (EPEL repository)
sudo dnf install epel-release && sudo dnf install htop

در top، خط ‎%Cpu(s)‎ بالای صفحه گاهی از فهرست پردازه‌ها مهم‌تر است:

• us و sy: زمان اجرای کد برنامه‌ها و کد کرنل. us بالا یعنی یک برنامه مشغول پردازش است؛ sy بالا معمولاً با تعداد زیاد فراخوانی سیستمی یا وقفه همراه است.
• wa: زمانی که CPU بیکار منتظر پایان عملیات دیسک مانده است. wa بالا همراه با load بالا نشانه گلوگاه دیسک است، نه کمبود CPU.
• st (steal): روی سرور مجازی، زمانی که هایپروایزر CPU را به ماشین‌های دیگر داده است. st بالا و پیوسته یعنی هاست میزبان شلوغ است و با تغییر تنظیمات داخل سرور حل نمی‌شود؛ باید با ارائه‌دهنده سرور در میان گذاشته شود.

داخل top با کلید P فهرست بر اساس CPU و با M بر اساس حافظه مرتب می‌شود. htop همین اطلاعات را خواناتر نشان می‌دهد و با کلید F5 نمای درختی را باز می‌کند تا پردازه‌های فرزند مثلاً PHP-FPM را زیر پردازه والد ببینید.

دستور vmstat: صف CPU، swap و I/O در یک نگاه

vmstat 1 5    # 5 samples, one second apart

خط اول خروجی vmstat میانگین از زمان بوت است و وضعیت فعلی را نشان نمی‌دهد؛ به خطوط بعدی نگاه کنید. ستون‌هایی که بیشتر به کار می‌آیند:

دستور free: آیا حافظه واقعاً پر است؟

free -h
free -h -s 5    # repeat every 5 seconds, Ctrl+C to stop

لینوکس حافظه آزاد را برای کش فایل‌ها (ستون buff/cache) به کار می‌برد، پس کم بودن ستون free طبیعی است. عدد مهم ستون available است: تخمین کرنل از حافظه‌ای که برنامه‌های جدید بدون رفتن به swap می‌توانند بگیرند. اگر available نزدیک صفر است و مصرف swap در حال افزایش، سرور واقعاً کمبود حافظه دارد.

عددی در ستون used مربوط به swap به‌تنها مشکل نیست؛ ممکن است صفحه‌هایی از مدت‌ها قبل در swap مانده باشند. مشکل وقتی است که ستون‌های si و so در vmstat پیوسته غیرصفرند. در این حالت لاگ کرنل را برای OOM Killer هم بررسی کنید (بخش journalctl).

df و du: فضای دیسک و inode

df -hT
df -i
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15
sudo journalctl --disk-usage
sudo lsof +L1     # deleted files still held open by a process

پر شدن پارتیشن / یا ‎/var معمولاً اول در دیتابیس و لاگ‌ها خودش را نشان می‌دهد، چون دیگر نمی‌توانند بنویسند. df -i تعداد inode را نشان می‌دهد؛ میلیون‌ها فایل کوچک مثل فایل‌های session، کش یا صف ایمیل می‌توانند inode را تمام کنند، در حالی که df -h هنوز فضای خالی نشان می‌دهد. نشانه آن خطای No space left on device با وجود فضای آزاد است.

du پوشه‌های حجیم را پیدا می‌کند و گزینه ‎-x مانع ورود به پارتیشن‌های دیگر می‌شود. اگر جمع خروجی du با df نمی‌خواند، احتمالاً فایلی حذف شده اما پردازه‌ای هنوز آن را باز نگه داشته است؛ lsof +L1 این فایل‌ها را نشان می‌دهد. نمونه رایج، فایل لاگ چرخیده‌ای است که سرویس هنوز در آن می‌نویسد و با ری‌استارت همان سرویس فضا آزاد می‌شود.

دستور iostat: آیا دیسک کند است؟

sudo apt install sysstat     # Debian / Ubuntu
sudo dnf install sysstat     # RHEL / Rocky / AlmaLinux

iostat -xz 1 3
sudo iotop -o                # which process is doing I/O (package: iotop)
pidstat -d 1 5               # per-process disk I/O from sysstat

iostat بخشی از بسته sysstat است. گزارش اول آن هم آمار از زمان بوت است و گزینه ‎-z دستگاه‌های بیکار را از خروجی حذف می‌کند. ستون‌هایی که باید دید:

• r_await و w_await: میانگین زمان پاسخ درخواست‌های خواندن و نوشتن به میلی‌ثانیه، شامل زمان ماندن در صف. عدد مناسب به نوع دیسک بستگی دارد؛ آن را با خروجی زمانی مقایسه کنید که سرور سالم بوده است.
• aqu-sz: میانگین طول صف درخواست‌های دستگاه. صف بلند و پیوسته یعنی درخواست‌ها سریع‌تر از توان دیسک می‌رسند.
• %util: درصد زمانی که دستگاه مشغول بوده است. طبق مستندات iostat، نزدیک ۱۰۰ بودن این عدد فقط برای دیسک‌هایی که درخواست‌ها را پشت سر هم پاسخ می‌دهند نشانه اشباع است. برای SSDهای جدید و آرایه‌های RAID که موازی کار می‌کنند، این عدد سقف توان دستگاه را نشان نمی‌دهد.

دستور ss: اتصالات شبکه و پورت‌های باز

ss -s                                           # summary
sudo ss -tulpn                                  # listening TCP/UDP ports with process
ss -Htn state established | wc -l               # established TCP connections
ss -Htn state established '( sport = :443 )' | wc -l
ss -Htn state syn-recv | wc -l

ss جایگزین netstat است و در بسته iproute2 روی بیشتر توزیع‌ها از پیش نصب شده است. ss -tulpn پورت‌هایی را که سرور روی آن‌ها گوش می‌دهد همراه با نام پردازه نشان می‌دهد؛ نمایش پردازه‌های کاربران دیگر به sudo نیاز دارد. هر پورتی که نمی‌شناسید، به‌خصوص روی 0.0.0.0، هم مسئله امنیتی است و هم باید علتش روشن شود.

تعداد اتصال‌های established روی پورت 443 را با زمان عادی مقایسه کنید تا معلوم شود کندی از افزایش واقعی بازدید است یا نه. تعداد زیاد اتصال در وضعیت syn-recv می‌تواند نشانه حجم زیاد درخواست اتصال نیمه‌کاره باشد. گزینه ‎-H سطر عنوان را حذف می‌کند تا wc -l عدد درست بدهد.

journalctl و systemctl: خطاها و سرویس‌های ازکارافتاده

systemctl --failed
journalctl -p err -b --no-pager | tail -50
journalctl -u nginx --since "1 hour ago" --no-pager
journalctl -k -b | grep -i -E "out of memory|oom-kill|killed process"
journalctl --list-boots
journalctl -b -1 -p warning --no-pager | tail -50

systemctl –failed سرویس‌هایی را نشان می‌دهد که متوقف شده‌اند. گزینه ‎-p err پیام‌های با اولویت err و شدیدتر را فیلتر می‌کند و ‎-b خروجی را به بوت فعلی محدود می‌کند. اگر پردازه‌ای مثل MySQL یا PHP-FPM بی‌دلیل ناپدید شده، پیام Out of memory در لاگ کرنل (‎-k) نشان می‌دهد OOM Killer آن را بسته است.

برای بررسی علت یک ری‌استارت ناخواسته، لاگ بوت قبلی را با ‎-b -1 بخوانید. این کار فقط وقتی ممکن است که ژورنال ماندگار باشد و در ‎/var/log/journal ذخیره شود؛ روی بعضی سرورها لاگ فقط در حافظه نگه داشته می‌شود و با ری‌استارت از بین می‌رود.

یک گزارش لحظه‌ای از سلامت سرور بسازید

برای مقایسه در آینده یا ارسال به پشتیبانی، خروجی همه دستورها را با یک اجرا در فایلی با تاریخ ذخیره کنید:

out="$HOME/health-$(hostname)-$(date +%F-%H%M).txt"
{
  date; uptime; nproc
  free -h
  df -hT; df -i
  vmstat 1 5
  iostat -xz 1 3
  ss -s
  systemctl --failed
  journalctl -p err -b --no-pager | tail -50
} > "$out" 2>&1
echo "saved to $out"

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

چه زمانی دستورات دستی کافی نیستند؟

این دستورها وضعیت همین لحظه را نشان می‌دهند. کندی ساعت سه بامداد تا صبح تمام شده و ردی در top باقی نمی‌گذارد. دستور sar از بسته sysstat، اگر جمع‌آوری دوره‌ای آن فعال باشد، تاریخچه CPU، حافظه و دیسک را نگه می‌دارد (sar -u، sar -r و sar -d). اما اگر این نشانه‌ها را دارید، به مانیتورینگ مداوم نیاز دارید:

• قطعی یا کندی را اول مشتری یا همکار گزارش می‌دهد.
• دیسک شبانه پر می‌شود و صبح فقط نتیجه‌اش را می‌بینید.
• نمی‌توانید بگویید کندی از چه روزی شروع شده یا با کدام تغییر همزمان بوده است.
• تعداد سرورها آن‌قدر زیاد است که بررسی دستی همه‌شان در یک روز ممکن نیست.

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

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

load average چه عددی خطرناک است؟

عدد ثابتی وجود ندارد. load را با تعداد هسته‌ها (nproc) مقایسه کنید. loadی که چند دقیقه پیوسته از تعداد هسته‌ها بیشتر است ارزش بررسی دارد، به‌خصوص اگر همزمان کاربران کندی را حس می‌کنند.

چرا free حافظه آزاد کمی نشان می‌دهد در حالی که سرور مشکلی ندارد؟

کرنل حافظه بی‌مصرف را برای کش فایل‌ها به کار می‌برد و در صورت نیاز آزادش می‌کند. به ستون available نگاه کنید، نه free.

top بهتر است یا htop؟

هر دو داده یکسانی از کرنل می‌خوانند. top روی تقریباً همه سرورها نصب است و برای اسکریپت (با گزینه ‎-b) مناسب‌تر است؛ htop برای بررسی تعاملی خواناتر است.

آیا اجرای این دستورها روی سرور عملیاتی خطر دارد؟

این دستورها چیزی را تغییر نمی‌دهند و سربارشان کم است. تنها استثنا du روی پوشه‌هایی با میلیون‌ها فایل است که خودش I/O زیادی ایجاد می‌کند؛ آن را روی پوشه مشخص و با اولویت پایین اجرا کنید، مثلاً ionice -c3 du -xh --max-depth=1 /var.