راهنمای جامع پایش سرور لینوکس

سرورهای لینوکس در شبکه‌های ایرانی معمولاً اقلیت‌اند، ولی اقلیت مهمی: وب‌سرور nginx جلوی اپلیکیشن‌ها، سرور ایمیل، فایروال یا VPN، پایگاه دادهٔ PostgreSQL یا MySQL، و چند ماشین Docker. و تقریباً همیشه کمتر از ویندوزها پایش می‌شوند، چون «لینوکس که خراب نمی‌شود». لینوکس خراب نمی‌شود، تا روزی که دیسک از لاگ پر شود، inodeها تمام شوند، یا سرور شش ماه آپدیت امنیتی نگیرد چون apt روی یک قفل گیر کرده بود.

این راهنما تمام چیزهایی را که روی یک سرور لینوکس باید پایید با دستورهای دقیقش مرور می‌کند. مثال‌ها روی Ubuntu/Debian و RHEL/Rocky/AlmaLinux آزموده شده‌اند؛ جایی که فرق دارند، هر دو را آورده‌ام. اصول کلی پایش، لایه‌ها و آستانه‌ها را در راهنمای جامع پایش سرور نوشته‌ام و اینجا تکرار نمی‌کنم.

CPU و load average

اولین چیزی که مدیران ویندوزی در لینوکس گیج‌شان می‌کند load average است: سه عدد در خروجی uptime و top، میانگین ۱، ۵ و ۱۵ دقیقه‌ای. load تعداد پروسس‌هایی است که یا در حال اجرا روی CPU هستند یا منتظر آن‌اند، به‌علاوهٔ پروسس‌هایی که در حالت D (انتظار غیرقابل‌وقفه، معمولاً برای I/O دیسک یا NFS) گیر کرده‌اند. همین نکتهٔ آخر مهم است: load بالا همیشه یعنی CPU شلوغ نیست.

uptime
nproc                       # number of CPUs, to compare load with
top -b -n 1 | head -n 15
vmstat 5 5                  # r = runnable, b = blocked (usually on I/O), wa = I/O wait %
ps -eo state,pid,cmd | awk '$1=="D"'   # processes stuck in uninterruptible sleep

قاعدهٔ سرانگشتی: load پانزده‌دقیقه‌ای پایدار بیش از تعداد هسته‌ها (خروجی nproc) ارزش بررسی دارد؛ بیش از دو برابر آن، تقریباً همیشه کاربران کندی را حس می‌کنند. ولی هشدار را روی load تنها نگذارید؛ همراه CPU و I/O wait معنا پیدا می‌کند.

رم: free، available و کش

خروجی free -m روی سرور سالمی که چند روز کار کرده معمولاً نشان می‌دهد ستون free خیلی کوچک است. این مشکل نیست. لینوکس رم بیکار را برای کش فایل‌ها استفاده می‌کند و هر وقت برنامه‌ای لازم داشت، پس می‌دهد. ستون معتبر available است که تخمین کرنل از رمی است که بدون swap کردن می‌شود به برنامه‌ها داد.

free -m
grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo
ps -eo pid,user,rss,cmd --sort=-rss | head -n 10    # top memory consumers (RSS in KB)
dmesg -T | grep -i -E 'out of memory|killed process'    # OOM killer activity
journalctl -k --since "-24h" | grep -i oom

نشانه‌های واقعی کمبود رم: available کمتر از ۵ تا ۱۰٪، swap که مدام در حال پر شدن است (ستون‌های si و so در vmstat غیرصفر و پایدار)، و از همه روشن‌تر، پیام OOM killer در لاگ کرنل. OOM killer یعنی کرنل برای نجات سیستم، پروسسی را کشته؛ اغلب همان پایگاه داده یا اپلیکیشن اصلی که بیشترین رم را داشت. اگر این پیام را دیدید و هشداری نگرفته بودید، پایشتان جای خالی دارد.

دیسک: فضا، inode و I/O

سه چیز جدا که هر سه باید پایش شوند:

df -hT -x tmpfs -x devtmpfs -x overlay      # space per filesystem
df -i -x tmpfs -x devtmpfs -x overlay       # inodes per filesystem
iostat -x 5 3                               # per-device utilization and latency (sysstat package)
du -xh --max-depth=1 /var | sort -rh | head # what is filling /var

inode شمارهٔ فایل‌هاست؛ هر فایل و پوشه یک inode می‌گیرد و تعدادشان هنگام ساخت فایل‌سیستم (ext4) ثابت می‌شود. سرور ایمیل، کش PHP session یا اپلیکیشنی که میلیون‌ها فایل کوچک می‌سازد، می‌تواند inode را تمام کند در حالی که دیسک نیمه‌خالی است. پیغام خطا همان «No space left on device» است و df -h چیز غیرعادی‌ای نشان نمی‌دهد؛ دقیقاً به همین دلیل باید جدا پایش شود. فایل‌سیستم XFS (پیش‌فرض RHEL) inode را پویا تخصیص می‌دهد و کمتر به این مشکل می‌خورد.

یک دام رایج دیگر: فایل لاگ بزرگی که با rm پاک شده ولی پروسسی هنوز بازش نگه داشته. فضا آزاد نمی‌شود تا پروسس ری‌استارت شود. پیدا کردنش:

lsof +L1 2>/dev/null | head      # deleted files still held open

برای I/O، در خروجی iostat -x به ستون‌های r_await و w_await (میانگین زمان هر درخواست به میلی‌ثانیه) و %util نگاه کنید. %util نزدیک ۱۰۰ روی دیسک‌های SSD و آرایه‌ها لزوماً به معنای اشباع نیست، چون این دیسک‌ها درخواست‌ها را موازی انجام می‌دهند؛ await بالا نشانهٔ مطمئن‌تری است.

شبکه

ip -s link                    # per-interface bytes, packets, errors, drops
ss -s                         # socket summary
ss -tn state established | wc -l
ss -tulpn                     # listening ports and owning processes
sar -n DEV 5 3                # per-interface throughput (sysstat)

خطا و drop روی کارت شبکه (در خروجی ip -s link) معمولاً نشانهٔ کابل، درایور یا mismatch در duplex است و در هیچ نمودار ترافیکی دیده نمی‌شود. تعداد اتصال‌های برقرار هم سنجهٔ مفیدی است: جهش ناگهانی ممکن است ترافیک واقعی باشد، نشت اتصال در اپلیکیشن، یا حمله.

systemd: سرویس‌ها و unitهای خراب

روی توزیع‌های امروزی تقریباً همه‌چیز سرویس systemd است و systemd خودش بهترین منبع وضعیت آن‌هاست:

systemctl --failed
systemctl is-active nginx postgresql
systemctl status nginx --no-pager
systemctl show nginx -p NRestarts      # how many times systemd restarted it
journalctl -u nginx --since "-1h" --no-pager

دو نکته: سرویسی که Restart=always دارد و هر چند دقیقه crash می‌کند، در systemctl --failed دیده نمی‌شود چون systemd دوباره بالایش می‌آورد. شمارندهٔ NRestarts این را نشان می‌دهد. دوم، timerهای systemd (جایگزین cron) هم unit هستند و اگر شکست بخورند در فهرست failed می‌آیند؛ بکاپ شبانه‌ای که با timer اجرا می‌شود و شکست خورده را اینجا می‌بینید.

لاگ‌ها و journalctl

journald همهٔ خروجی سرویس‌ها و پیام‌های کرنل را جمع می‌کند. چند دستور که هر روز به کار می‌آیند:

journalctl -p err -b                    # errors since last boot
journalctl --since "2026-10-08 22:00" --until "2026-10-09 02:00"
journalctl -k -b -1                     # kernel messages from previous boot
journalctl --list-boots                 # boot history: unexpected reboots
journalctl --disk-usage
sudo journalctl --vacuum-size=1G        # shrink journal

روی برخی توزیع‌ها journal به‌طور پیش‌فرض فقط در حافظه است و با ریبوت پاک می‌شود. اگر /var/log/journal وجود ندارد، آن را بسازید (یا Storage=persistent را در /etc/systemd/journald.conf بگذارید) تا بعد از خاموشی ناگهانی بتوانید ببینید پیش از آن چه شد. اگر لاگ اپلیکیشن‌ها را از چند سرور باید یکجا جستجو کنید، جمع‌آوری متمرکز لاگ کار ابزارهایی مثل LogMug است؛ پایش سرور و مدیریت لاگ مکمل هم‌اند، نه جایگزین هم.

امنیت: SSH، sudo و فایروال

هر سرور لینوکسی که SSH آن از اینترنت در دسترس است، همین حالا در حال حملهٔ حدس رمز است. این را به‌عنوان یک واقعیت بپذیرید و پایشش کنید:

# Debian/Ubuntu
grep -c 'Failed password' /var/log/auth.log
# RHEL family
grep -c 'Failed password' /var/log/secure
# Either, via journald (unit is "ssh" on Ubuntu, "sshd" on RHEL)
journalctl -u ssh -u sshd --since "-1h" | grep 'Failed password' |
  grep -oE 'from [0-9.]+' | sort | uniq -c | sort -rn | head
lastb -n 20        # recent failed logins from btmp

ورود ناموفق به‌تنهایی نگران‌کننده نیست اگر ورود با رمز بسته باشد (PasswordAuthentication no در sshd_config). آنچه نگران‌کننده است: ورود موفق از آی‌پی ناآشنا، کاربر جدید، و عضو جدید در گروه sudo (Debian/Ubuntu) یا wheel (RHEL).

getent group sudo wheel
awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd     # regular users and their shells
awk -F: '$3 == 0 {print $1}' /etc/passwd                 # anyone besides root with UID 0?
grep -rv '^#' /etc/sudoers.d/ 2>/dev/null

فایروال هم باید روشن باشد و پایش شود. سه ابزار رایج:

sudo ufw status verbose            # Ubuntu
sudo firewall-cmd --state; sudo firewall-cmd --list-all   # RHEL family
sudo nft list ruleset              # underlying nftables

آپدیت امنیتی و ریبوت لازم

رایج‌ترین مشکلی که دیده‌ام: unattended-upgrades نصب و فعال است و همه خیالشان راحت است، ولی ماه‌هاست به‌خاطر یک بستهٔ نیمه‌نصب یا مخزن خارج از دسترس شکست می‌خورد. لاگش در /var/log/unattended-upgrades/ است. به‌جای اعتماد به «فعال بودن»، تعداد آپدیت امنیتی معوق و تاریخ آخرین نصب را پایش کنید. مشکل دیگر آپدیت کرنل است که تا ریبوت اثری ندارد؛ سروری که ۴۰۰ روز uptime دارد، تقریباً قطعاً کرنل آسیب‌پذیر اجرا می‌کند.

ساعت و سلامت دیسک

timedatectl                 # "System clock synchronized: yes"?
chronyc tracking            # offset from reference
chronyc sources -v
sudo smartctl -H /dev/sda   # overall SMART health (smartmontools)
sudo smartctl -A /dev/sda | grep -E 'Reallocated|Pending|Uncorrectable'
sudo smartctl -H /dev/nvme0

روی ماشین مجازی، smartctl چیزی برای گزارش ندارد؛ سلامت دیسک را باید روی میزبان پایش کرد. روی سرور فیزیکی، افزایش شمارندهٔ Reallocated_Sector_Ct یا Current_Pending_Sector مهم‌تر از خود نتیجهٔ PASSED است؛ دیسک اغلب تا چند روز پیش از خرابی هنوز PASSED گزارش می‌شود.

جدول آستانه‌های پیشنهادی برای لینوکس

روال پنج‌دقیقه‌ای وقتی سرور «کند» است

وقتی کسی می‌گوید سرور لینوکسی کند شده و هنوز نمی‌دانید چرا، این ترتیب را پیشنهاد می‌کنم. هر مرحله یکی از منابع را حذف یا تأیید می‌کند و در کمتر از پنج دقیقه معمولاً می‌دانید مشکل کجاست:

1. uptime: load چقدر است و رو به بالا می‌رود یا پایین؟ مقایسهٔ عدد ۱ دقیقه‌ای با ۱۵ دقیقه‌ای می‌گوید مشکل تازه است یا قدیمی.
2. dmesg -T | tail -n 30: پیام OOM، خطای دیسک یا خطای شبکه در کرنل؟ این‌ها را اول ببینید چون جواب را مستقیم می‌دهند.
3. vmstat 1 5: صف CPU (r)، پروسس‌های مسدود (b)، swap (si/so) و I/O wait.
4. top یا htop: کدام پروسس CPU یا رم را گرفته؟
5. iostat -x 1 5: کدام دیسک کند است و await چقدر است؟
6. free -m و df -h و df -i: رم available، فضا و inode.
7. ss -s و ip -s link: اتصال‌های غیرعادی یا خطای کارت شبکه؟
8. journalctl -p err --since "-1h": خطای سرویس‌ها در ساعت گذشته.

نکتهٔ مهم این روال: همه‌اش «حال» را نشان می‌دهد. اگر مشکل ساعت دو بامداد بوده و الان برطرف شده، هیچ‌کدام کمکی نمی‌کنند. به همین دلیل پایش دائمی با نمودار تاریخی ارزش دارد؛ یا دست‌کم بستهٔ sysstat را نصب و فعال کنید تا sar هر ده دقیقه یک عکس فوری از منابع نگه دارد و بعداً با sar -u -f /var/log/sysstat/saDD (در RHEL /var/log/sa/saDD) به گذشته نگاه کنید.

یک سناریوی رایج: دیسکی که شبانه پر شد

این الگو را آن‌قدر دیده‌ام که شاید رایج‌ترین حادثهٔ لینوکسی باشد. اپلیکیشنی که روی سرور اجرا می‌شود، به‌خاطر خطای پایگاه داده یا سرویس بیرونی، در هر ثانیه چند صد خط خطا با stack trace کامل می‌نویسد. فایل لاگ اپلیکیشن در /var/log یا در پوشهٔ خود برنامه است و logrotate برایش تنظیم نشده. در چند ساعت، فایل‌سیستم ریشه پر می‌شود. حالا پایگاه داده نمی‌تواند بنویسد، journald نمی‌تواند لاگ کند، و حتی ورود SSH گاهی کند یا ناموفق است چون نمی‌تواند فایل موقت بسازد.

چه چیزی جلوی این حادثه را می‌گرفت؟ اول، هشدار روی فضای دیسک با دو سطح: هشدار در ۸۵٪ که چند ساعت فرصت می‌داد. دوم، logrotate با maxsize برای هر فایل لاگی که اپلیکیشن‌ها می‌سازند. سوم، جدا کردن /var یا دست‌کم /var/log روی پارتیشن یا volume جدا، تا لاگ دیوانه فایل‌سیستم ریشه را نخواباند. و آخر، هشدار روی نرخ رشد: دیسکی که در یک ساعت ۱۰٪ پرتر شده، حتی اگر هنوز ۶۰٪ باشد، ارزش نگاه کردن دارد.

# /etc/logrotate.d/myapp
/opt/myapp/logs/*.log {
    daily
    maxsize 500M
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

اشتباه‌های رایج در پایش لینوکس

• اعتماد به free به‌جای available. نتیجه‌اش هشدار رم دائمی روی سرورهای سالم است.
• پایش نکردن inode. روز حادثه هیچ نموداری دلیل را نشان نمی‌دهد.
• هشدار روی load تنها. load بالا بدون CPU بالا اغلب مشکل دیسک یا NFS است و هشدار CPU برایش گمراه‌کننده است.
• نادیده گرفتن ماشین‌های Docker. پوشهٔ /var/lib/docker با imageها و لاگ کانتینرها بی‌سروصدا دیسک را پر می‌کند. docker system df را بشناسید.
• journal غیرماندگار. بعد از کرش، هیچ لاگی از لحظه‌های پیش از آن نمی‌ماند.
• کرون‌جاب‌های بی‌صدا. بکاپی که با cron اجرا می‌شود و خطایش را به ایمیل محلی root می‌فرستد که کسی نمی‌خواند. یا خروجی را پایش کنید، یا یک چک بسازید که سن آخرین فایل بکاپ را بسنجد.

مورد آخر نمونهٔ خوبی از چیزی است که هیچ ابزار پایشی به‌طور پیش‌فرض نمی‌داند و باید خودتان تعریف کنید. یک اسکریپت bash کوتاه که سن فایل بکاپ را بسنجد و با کد خروج ۰، ۱ یا ۲ وضعیت را بگوید، در بیشتر ابزارها (Nagios، Zabbix، و در ServerMug به‌صورت چک سفارشی با اسکریپت) قابل استفاده است:

#!/bin/sh
# exit 0 = ok, 1 = warning, 2 = critical
f=$(ls -t /backup/*.tar.gz 2>/dev/null | head -n 1)
[ -z "$f" ] && { echo "no backup file"; exit 2; }
age=$(( ($(date +%s) - $(stat -c %Y "$f")) / 3600 ))
echo "value=$age"
[ "$age" -gt 48 ] && exit 2
[ "$age" -gt 26 ] && exit 1
exit 0

از دستور دستی تا پایش دائمی

همهٔ دستورهای این مقاله برای عیب‌یابی لحظه‌ای عالی‌اند، ولی پایش یعنی اجرای مداوم آن‌ها و هشدار وقتی چیزی از حد گذشت. گزینه‌ها: Prometheus با node_exporter برای سنجه‌ها (قوی ولی هشدارها و چک‌های امنیتی را خودتان باید بسازید)، Zabbix agent با قالب لینوکس، یا یک سنسور آماده. سنسور ServerMug روی لینوکس یک فایل اجرایی Go است که به‌صورت سرویس systemd به نام servermug-agent اجرا می‌شود و فقط ارتباط خروجی دارد؛ روش نصبش در نصب سنسور روی لینوکس و فهرست چک‌هایش در مرجع چک‌ها آمده است.

انتخاب ابزار هرچه باشد، فهرست بالا را چک‌لیست قرار دهید و مطمئن شوید هر ردیفش پوشش داده شده. لینوکس واقعاً کم خراب می‌شود؛ ولی وقتی می‌شود، اغلب از جایی است که کسی نگاهش نمی‌کرد.

منابع و مطالعهٔ بیشتر

• صفحهٔ راهنمای proc(5) — معنای دقیق فیلدهای /proc/meminfo و /proc/loadavg که همهٔ ابزارها از آن می‌خوانند.
• مستندات رسمی journalctl — همهٔ گزینه‌های فیلتر بر اساس زمان، unit، اولویت و بوت.
• پایش و مدیریت وضعیت و کارایی سیستم در RHEL 9 — راهنمای رسمی Red Hat برای ابزارهای کارایی.
• مستندات Ubuntu Server — راهنمای رسمی نگهداری، آپدیت و امنیت سرور اوبونتو.