آموزش مانیتورینگ سرور لینوکس — مصرف رم، 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 را باز کنید — داشبورد امن، بدون اینکه پورتی روی اینترنت باز باشد.

یک نکته‌ی صادقانه هم درباره‌ی هزینه‌ی خودِ مانیتورینگ: htop و btop فقط تا وقتی باز هستند مصرف دارند و vnstat از شمارنده‌های آماده‌ی کرنل می‌خواند، پس عملاً رایگان‌اند؛ اما Netdata یک سرویس دائمی است که هزاران متریک را ثانیه‌به‌ثانیه جمع و در حافظه نگه می‌دارد. روی سرورهای کوچک، همان btop برای نگاه لحظه‌ای به‌علاوه‌ی vnstat برای تاریخچه و اسکریپت هشدار بخش قبل، بدون هیچ سرویس اضافه‌ای کار را راه می‌اندازد.

قدم بعدی

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

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

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

ابزار واحدی وجود ندارد؛ انتخاب به سؤالی بستگی دارد که می‌پرسید. برای دیدن لحظه‌ای CPU و رم و پیداکردن پردازش مقصر، htop یا btop؛ برای تاریخچه‌ی ترافیک، vnstat؛ برای فشار دیسک، iostat از بسته‌ی sysstat؛ و برای فهمیدن علت، journalctl. اگر داشبورد وب با نمودار ثانیه‌به‌ثانیه می‌خواهید، Netdata گزینه‌ی رایج است. یک چیدمان عملی معمولاً از سه تکه ساخته می‌شود: یک ابزار زنده، یک ثبت‌کننده‌ی تاریخچه و یک هشداردهنده.

چرا free نشان می‌دهد رم سرور پر است ولی سرور کند نیست؟

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

Load average از چه عددی به بالا نگران‌کننده است؟

عدد ثابتی وجود ندارد؛ load را باید با تعداد هسته‌های CPU سنجید. load average میانگین تعداد پردازش‌هایی است که یا در حال اجرا بوده‌اند یا در صف CPU و دیسک منتظر مانده‌اند، پس روی سرور چهارهسته‌ای عدد ۳ یعنی مشغول ولی سالم و عدد ۸ یعنی به‌ازای هر هسته دو پردازش در صف است. تعداد هسته‌ها را با nproc بگیرید و سه عدد ۱، ۵ و ۱۵ دقیقه را کنار هم بخوانید تا بفهمید فشار تازه شروع شده یا دارد فروکش می‌کند.

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

با سه نگاه پشت‌سرهم، هر بار به یک ستون مشخص. اگر در htop نوارهای CPU پر است و پردازش‌ها در وضعیت R هستند، گلوگاه CPU است. اگر ستون available در free -h نزدیک صفر است یا Swap مدام مصرف می‌شود، کمبود رم دارید. و اگر load بالاست ولی درصدهای CPU پایین‌اند و چند پردازش در وضعیت D گیر کرده‌اند، مقصر دیسک است؛ با iostat -x 2 تأییدش کنید: %util نزدیک ۱۰۰ و await دورقمی یعنی دیسک اشباع شده.

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

سه دستور را به‌ترتیب اجرا کنید. vnstat -d و vnstat -m می‌گویند در هر روز و ماه چقدر ترافیک رفته و آمده، تا معلوم شود جهش واقعی است یا توهم. sudo iftop -i eth0 -P فهرست زنده‌ی اتصال‌ها را به‌ترتیب مصرف و همراه شماره‌ی پورت نشان می‌دهد. و ss -tunap هر اتصال را به نام و PID پردازش صاحبش وصل می‌کند. ترافیک خروجی زیاد به آی‌پی‌های ناشناس، از نشانه‌های کلاسیک سرور آلوده است.