مانیتورینگ سرور لینوکس Ubuntu؛ آموزش عملی CPU، RAM و سرویس‌ها

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

این آموزش برای مدیران VPS، برنامه‌نویسان Laravel و مسئولان عملیات نوشته شده است. نمونه دستورها برای نسخه‌های رایج Ubuntu با systemd مناسب‌اند؛ برخی ابزارهای اختیاری بسته جداگانه می‌خواهند. فرمان‌های بخش آموزشی عمدتاً فقط وضعیت را می‌خوانند و چیزی را Restart یا حذف نمی‌کنند. هدف این صفحه اجرای عملی فرمان‌ها و تفسیر خروجی Ubuntu است، نه تکرار راهنمای عمومی مانیتورینگ سرور چیست؟.

پیش از شروع مانیتورینگ Ubuntu چه اطلاعاتی لازم داریم؟

نسخه سیستم‌عامل، نام میزبان، تعداد هسته پردازنده، مقدار RAM، نوع فایل‌سیستم و سرویس‌های حیاتی را مشخص کنید. این داده‌ها کمک می‌کنند خروجی را در چارچوب درست بخوانیم. مثلاً Load Average برابر ۴ روی ماشین چهار vCPU با همان عدد روی سرور ۳۲ vCPU یک معنا ندارد.

cat /etc/os-release
hostnamectl
nproc
uptime
lsblk -f

این دستورها وضعیت سیستم را نمایش می‌دهند. خروجی lsblk نام و ساختار دیسک‌ها را نشان می‌دهد؛ اجرای عملیات پارتیشن‌بندی در این راهنما لازم نیست. هنگام اشتراک‌گذاری خروجی در فضای عمومی، نام میزبان و شناسه‌های حساس را پاک‌سازی کنید.

نام گزینه‌ها و رفتار برخی فرمان‌ها ممکن است با نسخه بسته‌ها تفاوت داشته باشد. برای بررسی تنظیمات سیستم و راهکارهای پشتیبانی‌شده، مستندات رسمی Ubuntu Server را مبنا قرار دهید و پیش از اجرای هر تغییر، نسخه سرور را مشخص کنید.

گام اول: مصرف CPU و Load Average را درست بخوانید

برای بررسی سریع پردازنده از top و uptime استفاده کنید. حالت Batch در top برای ثبت خروجی متنی مناسب است و نیاز به رابط تعاملی ندارد:

uptime
top -b -n 1 | head -n 25
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 15

CPU Usage نشان می‌دهد چه میزان پردازش انجام می‌شود؛ Load Average در لینوکس علاوه بر پردازش‌های آماده اجرا، بعضی فرایندهای منتظر I/O بدون وقفه را هم در بر می‌گیرد. بنابراین Load بالا الزاماً به معنی کمبود CPU نیست. برای تصمیم، روند چنددقیقه‌ای، تعداد vCPU و نشانه انتظار I/O را کنار هم بگذارید.

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

در خروجی top به بخش wa توجه کنید؛ این شاخص یکی از نشانه‌های انتظار I/O است، نه اندازه‌گیری مستقیم تأخیر دیسک. اگر CPU تقریباً بیکار اما Load بالا باشد، بررسی دیسک و فرایندهای در انتظار ارزش بیشتری دارد. برای تحلیل روند، یک Snapshot کافی نیست.

گام دوم: RAM، Swap و فشار حافظه را بررسی کنید

در Ubuntu، بالا بودن عدد «used» حافظه به‌تنهایی نشانه مشکل نیست؛ لینوکس از RAM برای Cache فایل هم استفاده می‌کند. ستون available در free تخمین بهتری از حافظه قابل استفاده بدون فشار شدید است.

free -h
vmstat 1 5
grep -E 'MemAvailable|SwapTotal|SwapFree' /proc/meminfo

در vmstat به ستون‌های si و so برای فعالیت Swap و به r برای صف پردازش‌ها نگاه کنید. نمونه اول vmstat ممکن است نمای تجمعی از زمان شروع سیستم باشد؛ برای روند کوتاه به نمونه‌های بعدی توجه کنید. کاهش available همراه با Swap پیوسته و کندی برنامه، دلیل قوی‌تری برای پیگیری است تا یک درصد مصرف ثابت.

آیا Swap مصرف‌شده همیشه مشکل است؟

خیر. وجود داده در Swap به‌تنهایی نشان نمی‌دهد سیستم اکنون تحت فشار است. نرخ جابه‌جایی داده به Swap، تأخیر درخواست‌ها و میزان حافظه قابل دسترس مهم‌ترند. خاموش‌کردن Swap یا تغییر تنظیمات حافظه بدون اندازه‌گیری می‌تواند شرایط سرور عملیاتی را بدتر کند.

گام سوم: فضای دیسک و inode را با هم پایش کنید

دو سرور ممکن است هر دو ۳۰ گیگابایت فضای آزاد داشته باشند؛ اما در یکی به دلیل تعداد بسیار زیاد فایل‌های کوچک، inodeها تمام شده باشند. نتیجه می‌تواند خطای ساخت فایل یا نشست باشد، حتی وقتی df -h فضای خالی نشان می‌دهد.

df -hT
df -i
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

df -hT ظرفیت و نوع فایل‌سیستم را نشان می‌دهد. df -i برای بررسی inode است. اگر لازم شد محل رشد داده را پیدا کنید، ابتدا فقط مسیرهای مشخص و محدود مانند /var/log را بررسی کنید:

sudo du -sh /var/log
sudo journalctl --disk-usage

فرمان du حتی در حالت خواندن ممکن است روی پوشه‌های بسیار بزرگ I/O ایجاد کند؛ بهتر است خارج از اوج ترافیک اجرا شود. برای آزادکردن فضا در این مرحله، Log یا فایل پایگاه‌داده را بدون برنامه حذف نکنید. دستورهای پاک‌سازی می‌توانند قابلیت عیب‌یابی و بازیابی را از بین ببرند.

چرا درصد پرشدن دیسک تمام ماجرا نیست؟

دیسکی با ظرفیت خالی کافی ممکن است به دلیل تأخیر بالای I/O، صف طولانی یا محدودیت IOPS کند باشد. برای بررسی این وضعیت، ابزار اختیاری iostat از بسته sysstat کاربرد دارد. اگر روی میزبان موجود است، iostat -xz 1 3 را اجرا و تأخیر و اشباع را همراه با رفتار برنامه تفسیر کنید. نصب بسته جدید روی سرور Production را جداگانه و با مجوز انجام دهید.

گام چهارم: کارت شبکه، اتصال‌ها و پورت‌های شنود را کنترل کنید

اختلال شبکه همیشه به معنی قطع کامل اتصال نیست. ممکن است رابط شبکه خطای RX/TX ثبت کند یا سرویس روی پورتی غیرمنتظره شنود کند. برای بررسی اولیه از فرمان‌های وضعیت‌خوان استفاده کنید:

ip -s link
ss -s
sudo ss -tlnp
ip route show

خروجی ss -tlnp نام فرایندها و پورت‌های شنود را نشان می‌دهد و ممکن است اطلاعات امنیتی داشته باشد؛ آن را عمومی منتشر نکنید. ss -s آمار کلی سوکت‌ها را می‌دهد، نه کیفیت مسیر اینترنت تا کاربران. برای این هدف باید DNS، TLS، HTTP و دسترس‌پذیری از نقاط بیرونی را هم بررسی کرد.

چگونه HTTP و TLS را بدون ایجاد بار اضافه بررسی کنیم؟

برای یک URL مجاز که متعلق به خودتان است، درخواست سبک HEAD یا GET با Timeout مشخص می‌تواند زمان برقراری اتصال و پاسخ را نشان دهد:

curl -sS -L --max-time 10 -o /dev/null \
  -w 'HTTP=%{http_code} connect=%{time_connect} ttfb=%{time_starttransfer}\n' \
  https://example.com/health

نتیجه HTTP 200 تنها ثابت می‌کند آن درخواست مشخص پاسخ دریافت کرده است، نه اینکه همه کاربران در همه شبکه‌ها به سرویس دسترسی دارند. برای تحلیل تفاوت مسیرها، راهنمای عیب‌یابی قطعی منطقه‌ای سایت را مطالعه کنید.

گام پنجم: سرویس‌های systemd را از نظر سلامت و خطا بررسی کنید

سرور ممکن است CPU و RAM طبیعی داشته باشد، اما Worker صف یا سرویس وب متوقف شده باشد. ابتدا فهرست سرویس‌های ناموفق و وضعیت یک سرویس مشخص را ببینید:

systemctl --failed
systemctl status nginx --no-pager
systemctl is-active nginx
journalctl -u nginx -n 50 --no-pager

نام nginx مثال است؛ می‌توانید آن را با سرویس واقعی پروژه مانند PHP-FPM یا Worker جایگزین کنید. دستورهای این بخش سرویس را Restart نمی‌کنند. در بعضی سیستم‌ها مشاهده بخشی از Logها به مجوز sudo نیاز دارد. پیش از اشتراک‌گذاری لاگ، IP، Cookie و داده حساس را حذف کنید.

گام ششم: Logها را هدفمند ببینید، نه بی‌نهایت جمع‌آوری کنید

مشاهده همه Logها در یک فایل بزرگ معمولاً پاسخ را کندتر پیدا می‌کند. بهتر است از زمان حادثه، نام سرویس و سطح خطا شروع کنید. در سیستم‌های دارای Journal می‌توانید خطاهای Boot جاری را محدود نمایش دهید:

journalctl -b -p err --no-pager -n 60
journalctl -u nginx --since '30 minutes ago' --no-pager -n 80

اگر از Laravel استفاده می‌کنید، خطاهای برنامه و وضعیت Worker را نیز کنار لاگ سرویس وب قرار دهید. یک خطای 502 ممکن است از PHP-FPM، اتصال برنامه یا محدودیت منابع ناشی شود؛ خواندن یک لاگ به‌تنهایی علت قطعی را اثبات نمی‌کند. برای مدیریت ورودهای مشکوک و رویدادهای امنیتی، راهنمای تحلیل لاگ امنیتی لینوکس موضوع جداگانه‌ای را بررسی می‌کند.

گام هفتم: فشار سرویس را با تجربه کاربر تطبیق دهید

فرض کنید systemctl is-active nginx عبارت active را نشان می‌دهد، اما API فروش ۱۰ ثانیه طول می‌کشد. سرویس فعال است ولی سلامت کاربردی آن مشخص نیست. زمان پاسخ درخواست، نرخ خطا، تأخیر دیتابیس و طول صف Laravel را در یک بازه زمانی مشترک ثبت کنید. اگر در همان لحظه MemAvailable کم و Swap فعال شده است، احتمال فشار حافظه را بررسی کنید؛ اگر منابع طبیعی‌اند، سراغ انتظار روی دیتابیس یا سرویس خارجی بروید.

برای مانیتورینگ چندلایه، از دو نوع بررسی استفاده کنید: داخل سرور برای CPU، RAM، Disk و Service؛ و بیرون سرور برای HTTP، TLS و زمان پاسخ از مسیر واقعی شبکه. این دو مکمل‌اند، نه جایگزین هم.

چطور خروجی فرمان‌ها را به مانیتورینگ دائمی تبدیل کنیم؟

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

ابزار یا رویکرد	کاربرد اصلی	مسئولیت یا محدودیت
top، free و ss	بررسی سریع وضعیت زنده Ubuntu	تاریخچه و اعلان خودکار ندارند
Prometheus + Node Exporter	متریک‌های زمان‌مند با کوئری و Alert	به طراحی ذخیره‌سازی و نگهداری نیاز دارد
Netdata	نمای زنده و ریزدانه متریک میزبان	مدل استفاده مرکزی و حفظ تاریخچه باید بررسی شود
Zabbix Agent	پایش سازمانی Host، Service و شبکه	تعریف Host، Template و Trigger نیاز به تنظیم دارد
Avaztek Monitoring	پایش منابع، سرویس، شبکه و لاگ در پنل فارسی	نصب و مجوز Agent و پوشش قابلیت‌های فعال باید بررسی شود

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

آستانه هشدار Ubuntu باید ثابت باشد یا پویا؟

آستانه نمونه مثل «بیشتر از ۹۰٪ مصرف دیسک» برای همه سرورها کافی نیست. روی حجم کوچک، ۱۰٪ فضای خالی ممکن است چند ساعت بیشتر دوام نیاورد؛ روی حجم بزرگ، شرایط متفاوت است. بهتر است درصد فضای خالی، سرعت رشد داده و اثر خطا بر سرویس را با هم ببینید. برای CPU هم مدت فشار و نرخ خطای کاربران مهم‌تر از یک جهش لحظه‌ای است.

یک سناریوی عملی: Ubuntu کند شده، اما علت CPU نیست

فرض کنید در یک سرور Ubuntu، کاربرها گزارش می‌دهند ثبت سفارش کند است. uptime عدد Load بالایی نشان می‌دهد، ولی top مصرف CPU زیاد ندارد. بررسی vmstat و iostat ممکن است انتظار I/O را نشان دهد. گام منطقی بعدی مقایسه زمان درخواست با لاگ دیتابیس و صف برنامه است، نه افزایش فوری تعداد vCPU.

1. زمان دقیق کندی و نسخه کد را ثبت کنید.
2. خروجی free -h، vmstat و df -hT را در همان بازه بررسی کنید.
3. وضعیت سرویس‌ها و خطاهای Journal را مشاهده کنید.
4. در صورت نیاز، وضعیت Disk I/O و زمان Query را با ابزار همان دیتابیس بسنجید.
5. تغییر احتمالی را ابتدا در محیط آزمایشی بررسی و بعد زمان پاسخ را با شرایط مشابه قبل مقایسه کنید.

این فرایند از اقدام‌هایی مثل Restart مکرر دیتابیس، حذف لاگ یا خاموش‌کردن سرویس جلوگیری می‌کند؛ اقدام‌هایی که ممکن است شواهد را از بین ببرند یا مشکل را بدتر کنند. برای تشخیص Lock و Query کند، راهنمای گلوگاه دیتابیس ادامه منطقی این بررسی است.

امنیت ابزار مانیتورینگ؛ دسترسی خواندن کافی است

برای جمع‌آوری بیشتر متریک‌های پایه Ubuntu، به دسترسی Root همیشگی نیاز نیست. Agent باید تا حد ممکن با سطح مجوز محدود اجرا شود و فقط برای شاخص‌هایی که واقعاً به مجوز بالاتر نیاز دارند، دسترسی مشخص داشته باشد. رمز، Token، کلید خصوصی و Cookie را در Log و داشبورد منتشر نکنید. اگر پنل از بیرون در دسترس است، احراز هویت، TLS و سطح دسترسی کاربران آن اهمیت حیاتی دارد.

همچنین جمع‌آوری Log حجیم، جست‌وجوی پیاپی کل دیسک و ثبت متریک با فاصله بسیار کوتاه می‌تواند بار ایجاد کند. قبل از اجرای گسترده، مصرف خود Agent و حجم انتقال داده را روی یک میزبان نمونه اندازه بگیرید.

معرفی Avaztek Monitoring برای سرورهای Ubuntu

Avaztek Monitoring طبق مستندات فعلی محصول، Agent لینوکسی برای جمع‌آوری Heartbeat، متریک‌های CPU، RAM، دیسک و شبکه و در شرایط مناسب Logها دارد. در پنل، بخش‌هایی برای مشاهده سرویس‌ها، هشدار و Recovery، مانیتورینگ شبکه و SSL و Log Explorer معرفی شده‌اند. این امکانات وقتی چند Ubuntu دارید کمک می‌کنند به جای اجرای دستی فرمان در هر میزبان، روند تغییر منابع و رخدادها را در یک محل ببینید.

برای مثال، اگر فضای دیسک سرور در حال پرشدن است، نمودار و هشدار می‌توانند فرصت رسیدگی ایجاد کنند؛ اما سامانه به‌جای مدیر، دلیل رشد داده را با قطعیت مشخص نمی‌کند. امکانات دقیق Agent، سطح دسترسی لازم، پلن و کانال اعلان را پیش از نصب روی Production بررسی کنید.

برای دیدن امکانات فعلی، صفحه پلن‌ها و ویژگی‌ها را ببینید و برای شروع از ثبت‌نام رسمی Avaztek Monitoring استفاده کنید. ابتدا یک Ubuntu آزمایشی را متصل و عددهای داشبورد را با خروجی مستقیم free و df مقایسه کنید.

پرسش‌های متداول درباره مانیتورینگ سرور Ubuntu

بهترین دستور برای بررسی مصرف CPU در Ubuntu چیست؟

برای بررسی لحظه‌ای top و برای فهرست پردازش‌ها ps کاربرد دارند. برای قضاوت دقیق باید زمان نمونه‌گیری، Load Average و انتظار I/O را هم بررسی کنید؛ یک خروجی کوتاه برای تشخیص روند کافی نیست.

در Ubuntu چگونه مصرف RAM را درست اندازه بگیریم؟

با free -h وضعیت حافظه را ببینید و به available بیشتر از صرفاً used توجه کنید. اگر کندی مشاهده می‌کنید، فعالیت Swap را در vmstat کنار زمان پاسخ سرویس بررسی کنید.

چرا با وجود فضای آزاد، Ubuntu خطای ذخیره فایل می‌دهد؟

ممکن است inodeها تمام شده باشند، مسیر فایل‌سیستم فقط خواندنی شده باشد یا برنامه مجوز نوشتن نداشته باشد. df -i و وضعیت mount را بررسی کنید؛ تنها df -h علت را مشخص نمی‌کند.

چطور وضعیت Nginx و PHP-FPM را مانیتور کنم؟

از systemctl is-active و systemctl status برای سرویس واقعی استفاده کنید و لاگ Journal را در بازه حادثه بخوانید. وضعیت Active برای اطمینان از صحت پاسخ HTTP و کارکرد برنامه کافی نیست.

آیا نصب Agent روی Ubuntu سرعت سایت را کم می‌کند؟

هر Agent مقداری منبع مصرف می‌کند؛ اثر دقیق به نرخ نمونه‌گیری و حجم لاگ وابسته است. روی یک سرور آزمایشی سربار CPU، RAM، I/O و شبکه را اندازه بگیرید و بعد استقرار را گسترش دهید.

آیا Avaztek Monitoring جای تمام دستورهای لینوکس را می‌گیرد؟

خیر. برای مشاهده روند و هشدار مناسب است، اما عیب‌یابی خاص مانند بررسی Query دیتابیس، مجوز فایل یا خرابی Kernel همچنان ممکن است به فرمان‌های خود سیستم‌عامل و ابزار تخصصی نیاز داشته باشد.

جمع‌بندی: از فرمان‌های Ubuntu به تصمیم عملی برسید

مانیتورینگ سرور لینوکس Ubuntu از اجرای top شروع می‌شود، اما با یک عدد CPU تمام نمی‌شود. فشار حافظه، inode، تأخیر دیسک، وضعیت سرویس، لاگ و تجربه کاربر را در زمان مشترک بررسی کنید؛ سپس برای تاریخچه و هشدار از ابزار مناسب کمک بگیرید. برای پایش پیوسته چند سرور و سرویس، سامانه مانیتورینگ آوازتک یکی از گزینه‌های قابل ارزیابی است.