آموزش مانیتورینگ سرور لینوکس — مصرف رم، CPU و پهنای باند

سایت کند شده، ربات جواب نمی‌دهد، یا فقط حس می‌کنید «سرور یک جایش می‌لنگد» — قدم اول هیچ‌وقت ری‌استارت نیست؛ نگاه‌کردن است. در این راهنما یاد می‌گیرید با چند دستور استاندارد لینوکس دقیقاً ببینید CPU، رم، دیسک و پهنای باند سرورتان چه می‌کنند، پردازش پرمصرف را در چند ثانیه پیدا کنید و در انتها یک هشداردهنده‌ی ساده بسازید که قبل از کاربران‌تان، خودتان از مشکل باخبر شوید.

تریاژ ۳۰ ثانیه‌ای: از uptime شروع کنید

وقتی با SSH وارد سرور می‌شوید (اگر هنوز راه نیفتاده‌اید، آموزش اتصال SSH را ببینید)، اولین دستور همیشه همین است:

uptime
# 14:32:10 up 42 days,  3:11,  1 user,  load average: 0.84, 1.02, 0.60

سه عدد آخر، load average در بازه‌های ۱، ۵ و ۱۵ دقیقه‌ی گذشته است: میانگین تعداد پردازش‌هایی که یا در حال اجرا بوده‌اند یا در صف اجرا (و دیسک) منتظر. این عدد به‌تنهایی معنی ندارد؛ باید آن را با تعداد هسته‌های CPU بسنجید:

nproc
# 4

قاعده‌ی سرانگشتی: تا وقتی load از تعداد هسته‌ها کمتر است، سرور نفس راحت می‌کشد. روی یک سرور ۴ هسته‌ای، load برابر ۳ یعنی مشغول ولی سالم؛ load برابر ۸ یعنی به‌ازای هر هسته دو پردازش در صف است و همه‌چیز کند پیش می‌رود. مقایسه‌ی سه عدد هم داستان را می‌گوید: اگر عدد ۱ دقیقه بالا ولی ۱۵ دقیقه پایین باشد، فشارْ تازه شروع شده؛ برعکسش یعنی بحران در حال فروکش‌کردن است.

رم: چرا free نشان می‌دهد حافظه پر است؟

پرتکرارترین سوءتفاهم مانیتورینگ لینوکس همین‌جاست. دستور را اجرا کنید:

free -h
#                total   used    free   shared  buff/cache  available
# Mem:           3.8Gi   1.1Gi   210Mi  25Mi    2.5Gi       2.4Gi
# Swap:          1.0Gi   0B      1.0Gi

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

نشانه‌ی واقعی کمبود رم دو چیز است: ستون available نزدیک صفر، و مصرف مداوم Swap. و بدترین حالتش وقتی است که هسته‌ی لینوکس مجبور شود پردازشی را بکشد. اگر برنامه‌ای «بی‌دلیل» ناپدید شده، ردپای OOM Killer را بگیرید:

journalctl -k | grep -i "out of memory"
# Out of memory: Killed process 1234 (mysqld) total-vm:2101960kB ...

پیام Out of memory: Killed process یعنی رم واقعاً تمام شده — یا باید مصرف را کم کنید یا پلن سرور را بزرگ‌تر.

htop: اتاق فرمان سرور

ابزار کلاسیک top همه‌جا هست، ولی htop همان اطلاعات را خواناتر و تعاملی نشان می‌دهد. نصب:

# Ubuntu / Debian
sudo apt install htop
# AlmaLinux / Rocky
sudo dnf install htop

بعد از اجرای htop، بالای صفحه نوارهای مصرف هر هسته‌ی CPU و رم را می‌بینید و پایین، جدول پردازش‌ها. ستون‌های مهم:

چند کلید میان‌بر که htop را ده برابر مفیدتر می‌کند: F6 برای مرتب‌سازی بر اساس هر ستون (مثلاً MEM%)، F5 برای نمای درختی که نشان می‌دهد کدام پردازش فرزند کدام است، F4 برای فیلتر بر اساس نام، و F9 برای بستن پردازش انتخاب‌شده.

پیداکردن پردازش پرمصرف با یک خط

لازم نیست همیشه htop باز کنید؛ برای گزارش سریع (یا استفاده در اسکریپت) این دو خط کافی است:

# ۱۰ پردازش پرمصرف از نظر رم
ps aux --sort=-%mem | head -n 11

# ۱۰ پردازش پرمصرف از نظر CPU
ps aux --sort=-%cpu | head -n 11

خروجی، نام کاربر، PID و درصد مصرف را کنار خط فرمان کامل پردازش نشان می‌دهد — معمولاً همین‌جا معلوم می‌شود مقصر یک mysqld باددار است، یک اسکریپت PHP در حلقه‌ی بی‌نهایت، یا پردازشی که اصلاً نمی‌شناسید (که خودش زنگ خطر امنیتی است؛ چک‌لیست امنیت سرور را مرور کنید).

دیسک: فضا یک بحث است، سرعت بحثی دیگر

فضای دیسک با df و du

df -h
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/vda1        40G   31G  7.2G  82% /

وقتی Use% از ۹۰٪ گذشت، وقت جست‌وجوی مقصر است. با du پوشه‌به‌پوشه پایین بروید:

sudo du -sh /var/* 2>/dev/null | sort -rh | head
# 12G   /var/log
# 8.5G  /var/lib/mysql
# ...

متهم‌های همیشگیِ دیسکِ پر: لاگ‌های چرخش‌نخورده در /var/log، بکاپ‌های قدیمی، و اگر داکر دارید، ایمیج‌ها و والیوم‌های بی‌استفاده (docker system df را ببینید — در آموزش داکر مفصل گفته‌ایم).

سرعت دیسک با iostat

دیسکِ «پر» را همه می‌فهمند؛ دیسکِ «خسته» را فقط iostat نشان می‌دهد. از بسته‌ی sysstat نصبش کنید:

sudo apt install sysstat        # اوبونتو/دبیان (dnf install sysstat در آلمالینوکس)
iostat -x 2

هر ۲ ثانیه یک گزارش می‌گیرید. دو ستون تعیین‌کننده:

• %util — چند درصد از زمان، دیسک مشغول بوده. اعداد نزدیک ۱۰۰٪ به‌صورت پیوسته یعنی دیسک اشباع شده است.
• r_await / w_await — میانگین زمان انتظار هر عملیات خواندن/نوشتن به میلی‌ثانیه. روی NVMe باید زیر ۱–۲ میلی‌ثانیه باشد؛ اگر اعداد دورقمی می‌بینید، یا دیسک زیر فشار شدید است یا سرویس‌دهنده NVMe واقعی نداده (روش راستی‌آزمایی را در مقاله‌ی KVM و NVMe نوشته‌ایم).

پهنای باند: vnstat برای تاریخچه، iftop برای لحظه

vnstat — حسابدار ترافیک

vnstat یک سرویس سبک است که مصرف ترافیک هر اینترفیس را به تفکیک ساعت، روز و ماه ثبت می‌کند — بدون شنود بسته‌ها، فقط از شمارنده‌های کرنل، پس عملاً هیچ باری روی سرور ندارد:

sudo apt install vnstat
sudo systemctl enable --now vnstat

چند ساعت که بگذرد، داده جمع می‌شود:

vnstat -d       # گزارش روزانه
#      day        rx      |     tx      |    total
#  2026-07-25   4.21 GiB  |  9.87 GiB  |  14.08 GiB
vnstat -m       # جمع ماهانه — برای پایش سقف ترافیک عالی است
vnstat -l       # نرخ لحظه‌ای (live)

iftop و ss — چه کسی دارد پهنای باند می‌خورد؟

وقتی نمودار پهنای باند ناگهان پرواز کرده، vnstat فقط می‌گوید «چقدر»؛ برای «چه کسی» سراغ iftop بروید:

sudo apt install iftop
sudo iftop -i eth0 -P

فهرست زنده‌ی اتصال‌ها را بر اساس مصرف می‌بینید — سوییچ -P شماره‌ی پورت‌ها را هم نشان می‌دهد تا بفهمید ترافیک مال وب‌سرور است، دیتابیس است یا چیزی غیرمنتظره. برای فهرست دقیق اینکه کدام پردازش روی کدام پورت به کجا وصل است:

ss -tunap | head -n 20
ss -s          # آمار خلاصه‌ی کل اتصال‌ها

لاگ‌ها: journalctl را جدی بگیرید

عددها می‌گویند «مشکلی هست»؛ لاگ‌ها می‌گویند «چرا». روی همه‌ی توزیع‌های مدرن (اوبونتو ۲۲.۰۴/۲۴.۰۴، آلمالینوکس ۹) systemd-journald لاگ همه‌ی سرویس‌ها را یک‌جا دارد:

# فقط خطاهای بوت فعلی
journalctl -p err -b

# لاگ زنده‌ی یک سرویس خاص
journalctl -u nginx -f

# هر اتفاقی در یک ساعت گذشته
journalctl --since "1 hour ago"

# لاگ‌ها چقدر دیسک گرفته‌اند؟
journalctl --disk-usage

اگر خط آخر عدد چند گیگابایتی داد، با sudo journalctl --vacuum-size=500M حجمش را کوچک کنید. عادت طلایی: هر بار سرویسی «بی‌دلیل» ری‌استارت شد یا خطای ۵۰۲ دیدید، اولین مقصد journalctl -u SERVICE -n 50 است، نه گوگل.

هشدار خودکار: cron + یک پیام تلگرام، بدون هیچ سرویس خارجی

مانیتورینگ واقعی یعنی لازم نباشد خودتان مدام نگاه کنید. با یک ربات تلگرام (ساختش دو دقیقه با BotFather طول می‌کشد — آموزش ربات تلگرام) و یک اسکریپت ده‌خطی، سرور خودش خبرتان می‌کند. فایل /root/watchdog.sh را بسازید:

#!/bin/bash
TOKEN="123456789:AAExxxxxxxxxxxxxxxxxxx"   # توکن ربات
CHAT="123456789"                            # آی‌دی عددی چت شما
CORES=$(nproc)
LOAD=$(awk '{print $1}' /proc/loadavg)
MEM=$(free | awk '/Mem/ {printf "%d", $3/$2*100}')
DISK=$(df / --output=pcent | tail -1 | tr -dc '0-9')

MSG=""
awk -v l="$LOAD" -v c="$CORES" 'BEGIN {exit !(l > c*1.5)}' \
  && MSG="$MSG | Load: $LOAD ($CORES cores)"
[ "$MEM"  -gt 90 ] && MSG="$MSG | RAM: ${MEM}%"
[ "$DISK" -gt 90 ] && MSG="$MSG | Disk: ${DISK}%"

if [ -n "$MSG" ]; then
  curl -s "https://api.telegram.org/bot${TOKEN}/sendMessage" \
    -d chat_id="$CHAT" -d text="ALERT $(hostname)$MSG"
fi

اجرایی‌اش کنید و هر ۵ دقیقه یک بار در cron بگذارید:

chmod +x /root/watchdog.sh
crontab -e
# این خط را اضافه کنید:
*/5 * * * * /root/watchdog.sh >/dev/null 2>&1

منطق اسکریپت ساده است: اگر load از ۱.۵ برابر تعداد هسته‌ها بیشتر شود، یا رم/دیسک از ۹۰٪ بگذرد، پیام می‌آید؛ در حالت عادی هیچ. آستانه‌ها را با شرایط خودتان تنظیم کنید و اگر پیام‌رسان دیگری ترجیح می‌دهید، همان curl را به هر API دلخواه (بله، وب‌هوک، ایمیل) بزنید — منطق تغییری نمی‌کند.

ابزارهای گرافیکی سبک: btop و Netdata

btop — همان htop، فقط خوش‌عکس‌تر

btop نسل جدیدتر مانیتورهای ترمینالی است: نمودار تاریخچه‌ی CPU و رم، فهرست دیسک و شبکه، همه در یک صفحه و بدون هیچ سرویس اضافه. در اوبونتو ۲۲.۰۴ به بعد داخل مخازن است:

sudo apt install btop   # (dnf install btop در آلمالینوکس ۹ با مخزن EPEL)
btop

Netdata — داشبورد وب کامل با یک خط نصب

اگر داشبورد مرورگری با نمودارهای ثانیه‌به‌ثانیه می‌خواهید، Netdata با یک خط نصب می‌شود:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh

و روی پورت 19999 بالا می‌آید. اما همین‌جا یک هشدار امنیتی مهم: به‌صورت پیش‌فرض این داشبورد روی همه‌ی اینترفیس‌ها گوش می‌دهد؛ یعنی هر کسی روی اینترنت جزئیات کامل سرور شما را می‌بیند. حتماً آن را به localhost محدود کنید — در /etc/netdata/netdata.conf:

[web]
    bind to = 127.0.0.1

بعد sudo systemctl restart netdata و برای دیدن داشبورد، از سیستم خودتان یک تونل SSH بزنید:

ssh -L 19999:localhost:19999 root@SERVER_IP

حالا در مرورگر خودتان http://localhost:19999 را باز کنید — داشبورد امن، بدون اینکه پورتی روی اینترنت باز باشد.

سؤالات پرتکرار

چرا لینوکس نشان می‌دهد رم تقریباً پر است، ولی سرور کند نیست؟

چون لینوکس رم بیکار را به کش دیسک تبدیل می‌کند تا خواندن فایل‌ها سریع‌تر شود؛ این کش هر لحظه برنامه‌ای رم بخواهد آزاد می‌شود. در خروجی free -h به‌جای ستون free، ستون available را نگاه کنید — معیار واقعی همان است. رم فقط وقتی واقعاً مشکل است که available نزدیک صفر باشد یا در لاگ کرنل پیام «Out of memory: Killed process» ببینید.

Load average بالا دقیقاً یعنی چه؟

یعنی به‌طور میانگین چند پردازش هم‌زمان یا در حال اجرا بوده‌اند یا در صف CPU و دیسک منتظر. عدد را با خروجی nproc مقایسه کنید: load پایین‌تر از تعداد هسته‌ها طبیعی است؛ بالاتر از آن به‌صورت پیوسته یعنی صف تشکیل شده. حواس‌تان باشد load بالا همیشه تقصیر CPU نیست — پردازش‌های منتظرِ دیسک (وضعیت D در htop) هم load را بالا می‌برند.

چطور بفهمم کدام برنامه پهنای باند را مصرف می‌کند؟

برای جمع مصرف در طول زمان vnstat -d، برای دیدن لحظه‌ای اتصال‌ها sudo iftop -i eth0 -P، و برای اینکه بفهمید هر اتصال مال کدام پردازش است ss -tunap. ترکیب همین سه دستور، تقریباً هر معمای ترافیکی را حل می‌کند.

آیا مانیتورینگ خودش سرور را سنگین نمی‌کند؟

ابزارهای این مقاله عملاً نه: htop و btop فقط موقع بازبودن مصرف ناچیزی دارند، vnstat از شمارنده‌های آماده‌ی کرنل می‌خواند و اسکریپت cron هر ۵ دقیقه چند میلی‌ثانیه CPU می‌گیرد. تنها مورد قابل‌اندازه‌گیری Netdata است که معمولاً ۱ تا ۲ درصد یک هسته و حدود ۱۵۰ تا ۲۰۰ مگابایت رم مصرف می‌کند — روی سرورهای خیلی کوچک حسابش را بکنید.

قدم بعدی

همین امروز سه کار را انجام دهید: htop و vnstat را نصب کنید، یک بار free -h و df -h را با چشم باز بخوانید، و اسکریپت هشدار تلگرام را فعال کنید — از این به بعد سرور قبل از بحران صدای‌تان می‌کند. اگر مانیتورینگ نشان داد منابع واقعاً کم است، مسیر ارتقا را با راهنمای انتخاب مشخصات سرور جلو بروید؛ و اگر هنوز سروری برای تمرین ندارید، یک سرور ابری ساعتی بسازید، یکی دو ساعت همه‌ی این دستورها را امتحان کنید و فقط هزینه‌ی همان چند ساعت را بدهید.