مانیتورینگ VPS؛ مهم‌ترین معیارها و آستانه‌های هشدار

دو VPS با چهار vCPU و هشت گیگابایت RAM دارید. روی اولی CPU معمولاً ۳۰٪ است، ولی سرویس هر چند دقیقه کند می‌شود؛ روی دومی CPU به ۸۵٪ می‌رسد و کاربران مشکلی نمی‌بینند. کدام VPS واقعاً در خطر است؟ مانیتورینگ VPS زمانی کاربردی است که استفاده از منابع را با اشباع، خطا و تجربه واقعی سرویس مرتبط کنیم. درصد مصرف پردازنده، به‌تنهایی وضعیت سرور مجازی را تعیین نمی‌کند.

این راهنما معیارهای ضروری مانیتورینگ سرور مجازی را به زبان عملی توضیح می‌دهد: CPU و Steal Time، RAM و Swap، Disk I/O، شبکه، Load Average، سرویس‌های حیاتی، Uptime و طراحی آستانه هشدار. علاوه بر فرمان‌های خواندنی Linux، یک الگوی انتخاب شاخص و داشبورد متناسب با اندازه VPS ارائه می‌کنیم. اگر صرفاً به دنبال دستورهای پایه Ubuntu هستید، آموزش مانیتورینگ Ubuntu مرجع مستقل است؛ این مطلب بر شاخص‌های تصمیم، مرز مجازی‌سازی و هشدارهای قابل اقدام تمرکز دارد.

VPS چه تفاوتی با سرور اختصاصی در مانیتورینگ دارد؟

در VPS، بخشی از منابع فیزیکی با ماشین‌های دیگر میزبان مشترک است و رفتار Hypervisor یا سیاست ارائه‌دهنده می‌تواند در کارایی مهم باشد. ممکن است چهار vCPU در پنل دیده شود اما به دلیل رقابت روی Host، زمان پردازنده واقعاً در دسترس نباشد. در برخی محیط‌ها نیز دسترسی به آمار لایه مجازی‌سازی مانند Steal Time محدود است. قبل از تفسیر داده، بدانید VPS روی چه نوع مجازی‌سازی و با چه سیاست CPU/IOPS ارائه شده است.

شاخص	چه چیزی را می‌گوید؟	چه چیزی را ثابت نمی‌کند؟
CPU Usage	میزان استفاده از پردازنده تخصیص‌یافته	کیفیت زمان‌بندی Hypervisor را به‌تنهایی نشان نمی‌دهد
Steal Time	در بعضی ماشین‌های مجازی، زمان انتظار پردازنده در Host	در همه پلتفرم‌ها به یک شکل گزارش نمی‌شود
Load Average	تعداد متوسط کارهای آماده اجرا و بعضی انتظارهای I/O	درصد CPU یا علت قطعی نیست
Disk Latency	زمان انتظار عملیات I/O	فقط با فضای خالی دیسک سنجیده نمی‌شود
Service Availability	پاسخ‌دادن یک Endpoint مشخص	سلامت همه کاربران یا کارکرد کامل برنامه نیست

معیار اول: CPU Usage و Steal Time را کنار هم ببینید

برای مشاهده پردازش‌های پرمصرف و Load، این فرمان‌های بدون تغییر وضعیت را روی VPS لینوکسی اجرا کنید:

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

در برخی نسخه‌های top، ستون st نشان‌دهنده Steal Time است. اگر هم‌زمان با افزایش تأخیر برنامه، Steal Time به‌طور پایدار بالا می‌رود، باید احتمال رقابت منابع Host را بررسی کنید. با این حال عدد صفر یا نبود ستون، ثابت نمی‌کند Hypervisor هیچ محدودیتی اعمال نمی‌کند؛ نوع مجازی‌سازی و دسترس‌پذیری متریک مؤثر است.

CPU بالا چه زمانی هشدار مهم است؟

فرض کنید پردازنده برای یک دقیقه به ۹۵٪ می‌رسد چون Job زمان‌بندی‌شده‌ای انجام می‌شود و زمان پاسخ API ثابت می‌ماند. این رخداد ممکن است طبیعی باشد. در مقابل، CPU حدود ۷۰٪ همراه با رشد صف درخواست و خطای HTTP می‌تواند اهمیت بیشتری داشته باشد. هشدار را از ترکیب مدت زمان فشار، رشد درخواست معوق و اثر واقعی بسازید؛ عدد ثابت برای همه VPSها انتخاب مناسبی نیست.

معیار دوم: RAM و Swap را از روی فشار حافظه تفسیر کنید

ستون used در خروجی free شامل استفاده‌های طبیعی سیستم‌عامل از حافظه است. برای تصمیم درباره فشار واقعی، مقدار available، فعالیت Swap، OOM و رفتار پردازش‌ها را بررسی کنید.

free -h
vmstat 1 5
grep -E 'MemAvailable|SwapTotal|SwapFree' /proc/meminfo
journalctl -k -p warning --since '2 hours ago' --no-pager -n 80

در vmstat ستون‌های si و so برای جابه‌جایی Swap اهمیت دارند؛ نمونه نخست ممکن است نمای تجمعی از شروع سیستم باشد. اگر سیستم مرتب داده به Swap می‌فرستد و زمان پاسخ بدتر می‌شود، فشار حافظه را بررسی کنید. در خروجی Journal ممکن است رویدادهای OOM یا خطای Kernel دیده شوند؛ در انتشار عمومی لاگ، مشخصات حساس را حذف کنید.

آیا غیرفعال‌کردن Swap VPS را سریع‌تر می‌کند؟

نه به شکل تضمینی. بدون Swap، کمبود RAM می‌تواند زودتر به خاتمه پردازش یا OOM منجر شود. وجود Swap نیز جای RAM کافی را نمی‌گیرد. تصمیم تغییر Swap را براساس اندازه RAM، نوع برنامه، میزان خطای OOM و سیاست عملیاتی بگیرید؛ صرف پرشدن بخشی از Swap دلیل حذف آن نیست.

معیار سوم: Disk I/O و Latency را جدا از فضای خالی بسنجید

یک VPS ممکن است ۵۰ گیگابایت فضای آزاد داشته باشد اما پایگاه‌داده به دلیل محدودیت IOPS یا تأخیر ذخیره‌سازی کند شود. باید ظرفیت، inode و کیفیت عملیات خواندن/نوشتن را جدا بررسی کرد:

df -hT
df -i
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
# If sysstat is already installed:
iostat -xz 1 3

در iostat به شاخص‌هایی مانند await برای مدت انتظار I/O و نرخ عملیات در ثانیه توجه کنید. تفسیر درصد %util روی NVMe یا صف‌های چندگانه مثل دیسک ساده قدیمی نیست؛ مقدار ۱۰۰٪ به‌تنهایی علت قطعی یا ظرفیت نهایی همه دیسک‌ها را ثابت نمی‌کند. ابزار iostat ممکن است نصب نباشد؛ نصب بسته جدید روی Production باید جداگانه بررسی شود.

رشد فضای ذخیره‌سازی را چگونه پیش‌بینی کنیم؟

اگر مصرف دیسک از ۶۰٪ به ۷۵٪ در یک هفته رسیده، عدد ۷۵٪ تنها بخشی از مسئله است. نرخ رشد روزانه و زمان احتمالی رسیدن به آستانه بحرانی را نیز بسنجید. لاگ‌های حجیم، Snapshot، Backup و پوشه آپلود را با مجوز بخوانید؛ حذف فوری Log یا فایل پایگاه‌داده بدون شواهد می‌تواند بازیابی را دشوار کند. برای طراحی سنجش ظرفیت، مقاله پیش‌بینی ظرفیت سرور یک راهنمای مستقل دارد.

معیار چهارم: شبکه VPS فقط پهنای باند نیست

برای شبکه، نرخ دریافت و ارسال، خطاهای کارت شبکه، از دست‌رفتن بسته و تأخیر تا سرویس واقعی را در نظر بگیرید. اگر پهنای باند اختصاصی مشخصی در قرارداد VPS دارید، رشد ترافیک نزدیک سقف را با زمان پاسخ HTTP تطبیق دهید. فرمان‌های زیر اطلاعات محلی سیستم را نمایش می‌دهند:

ip -s link
ss -s
ip route show
curl -sS --max-time 10 -o /dev/null \
  -w 'HTTP=%{http_code} TTFB=%{time_starttransfer}\n' \
  https://example.com/health

URL نمونه باید با Endpoint خواندنی و مجاز خودتان جایگزین شود. تست از خود VPS ممکن است نشان دهد سرور به سرویس خودش دسترسی دارد، اما ثابت نکند کاربرانی در شبکه‌های دیگر به آن دسترسی دارند. برای مسیرهای بیرونی، Probe جداگانه و آزمون DNS/TLS از چند نقطه مفید است.

معیار پنجم: Load Average را نسبت به vCPU و I/O تفسیر کنید

Load Average معمولاً سه میانگین زمانی کوتاه، متوسط و بلند را نمایش می‌دهد. مقایسه آن با تعداد vCPU یک نشانه ابتدایی است، اما نباید به فرمول «Load بالاتر از تعداد هسته مساوی خرابی» تقلیل یابد؛ فرایندهای منتظر I/O هم می‌توانند Load را افزایش دهند.

اگر Load پیوسته بالا می‌ماند ولی CPU بیکار است، احتمال انتظار دیسک یا کارهای مسدودشده را بررسی کنید. اگر Load و CPU هر دو بالا هستند و صف برنامه رشد می‌کند، احتمال کمبود ظرفیت پردازش یا کد پرهزینه مطرح است. تصمیم Scaling زمانی معتبر است که سایر اجزا مانند دیتابیس و شبکه هم اندازه‌گیری شده باشند.

معیار ششم: Uptime و سلامت سرویس‌های حیاتی را جدا بسنجید

فرمان uptime زمان روشن‌بودن سیستم را نشان می‌دهد، اما ممکن است Nginx یا Worker Laravel از کار افتاده باشد. در VPS دارای systemd، وضعیت فرایندهای حیاتی را با نام صحیح بررسی کنید:

systemctl --failed
systemctl is-active nginx
systemctl status nginx --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager -n 60

نام سرویس را با پروژه واقعی تطبیق دهید؛ nginx فقط مثال است. در برنامه PHP، سلامت PHP-FPM و صف نیز مهم است. اگر systemctl is-active مقدار active بدهد، فقط فرایند موردنظر فعال است؛ صحت پاسخ Endpoint یا اتصال به دیتابیس تضمین نشده است.

هفت شاخص طلایی برای داشبورد VPS کوچک

شاخص	منبع پیشنهادی	چه سؤالی را جواب می‌دهد؟
CPU و Steal Time	Agent لینوکس / Hypervisor در صورت دسترسی	پردازنده واقعاً فرصت اجرای کار دارد؟
MemAvailable و Swap I/O	Agent و vmstat	فشار حافظه بر پاسخ برنامه اثر می‌گذارد؟
Disk await و فضای آزاد	iostat و df	گلوگاه ظرفیت است یا تأخیر دیسک؟
Network Errors و TTFB	ip و HTTP Probe	اختلال محلی است یا در مسیر شبکه؟
Load Average و Run Queue	uptime و vmstat	کارها پشت CPU یا I/O منتظر می‌مانند؟
سرویس‌های حیاتی	systemd و Health Endpoint	برنامه و وابستگی‌هایش پاسخ می‌دهند؟
نرخ خطای کاربر و Uptime بیرونی	Probe و گزارش وب‌سرور	کاربر واقعاً می‌تواند سرویس را استفاده کند؟

اگر صفحه مانیتورینگ شما ده‌ها نمودار دارد ولی نمی‌توانید به سؤال «چرا درخواست کند شد؟» جواب دهید، Dashboard شلوغ کمکی نمی‌کند. ترتیب کارت‌ها را بر اساس اثر تجاری و امکان اقدام تنظیم کنید.

آستانه هشدار VPS؛ از درصد ثابت به نشانه پایدار برسید

برای شروع ممکن است آستانه‌های آزمایشی مانند CPU بالای ۸۵٪ در پنج دقیقه، فضای آزاد کمتر از ۱۵٪، یا روند مداوم Swap Out تعریف کنید؛ این‌ها پیشنهاد اولیه‌اند و SLA یا مقدار استاندارد عمومی نیستند. VPS با دیسک ۲۰ گیگابایتی و VPS با دو ترابایت فضا را نباید با یک درصد یکسان اداره کرد. مقدار واقعی از تاریخچه استفاده و ریسک سرویس تعیین می‌شود.

وضعیت	نمونه هشدار اولیه	اقدام پیشنهادی
فشار پردازنده	CPU بالا همراه با تأخیر p95 سرویس	بررسی پردازش و Steal Time قبل از ارتقا
کمبود حافظه	MemAvailable کم، Swap Out و افزایش خطا	بررسی رشد RAM پردازش‌ها و OOM
رشد دیسک	پیش‌بینی رسیدن به حد بحرانی در چند روز	مشاهده مسیرهای رشد، بدون حذف فوری
اختلال دیسک	افزایش پایدار Latency I/O هم‌زمان با کندی برنامه	بررسی پایگاه‌داده و سیاست IOPS میزبان
قطعی سرویس	چند شکست متوالی از Probeهای معتبر	بررسی مسیر شبکه و وضعیت برنامه

برای جلوگیری از خستگی هشدار، مرحله Warning را از Critical جدا کنید و شرط رفع مشکل (Recovery) را نیز مشخص کنید. یک جهش ۲۰ ثانیه‌ای CPU نباید به‌اندازه خاموش‌شدن درگاه پرداخت هشدار فوری ایجاد کند. راهنمای هشدار هوشمند سرور طراحی Severity و جلوگیری از پیام کاذب را جدا توضیح داده است.

چطور یک VPS را در هفت روز مبناگذاری کنیم؟

1. روز اول: تعداد vCPU، RAM، حجم دیسک، IOPS قراردادی و سرویس‌های حیاتی را ثبت کنید.
2. روز دوم: نرخ نمونه‌گیری مناسب متریک‌های CPU، RAM، Disk و شبکه را تعیین کنید.
3. روز سوم: وضعیت Endpointهای اصلی و بازه طبیعی p95 زمان پاسخ را اندازه بگیرید.
4. روز چهارم: در محیط آزمایشی، یک خطای قابل بازگشت مانند توقف سرویس غیرحیاتی را شبیه‌سازی و زمان هشدار را بسنجید.
5. روز پنجم: روند مصرف دیسک و Peak ساعت‌های شلوغ را در نظر بگیرید.
6. روز ششم: نقش پاسخ‌گو، کانال اعلان، Recovery و سکوت زمان تعمیرات را مشخص کنید.
7. روز هفتم: آستانه‌های پرنویز را اصلاح و یک Runbook کوتاه برای هر هشدار Critical آماده کنید.

این برنامه شروع است، نه اینکه هفت روز داده برای پیش‌بینی فصلی یا ترافیک ویژه کافی باشد. برای فروشگاه یا سامانه دارای کمپین، داده دوره‌های شلوغ قبلی را هم بررسی کنید.

ابزار مناسب VPS: دستی، خودمیزبان یا سامانه آماده؟

فرمان‌های Linux برای عیب‌یابی ضروری‌اند، اما برای رخداد شبانه تاریخچه و اعلان کافی ندارند. اگر تیم DevOps دارید، Prometheus با Node Exporter و Grafana می‌تواند متریک‌های زمان‌مند و داشبورد سفارشی بسازد. Netdata برای مشاهده جزئی منابع مناسب است؛ Zabbix برای ترکیب شبکه و Host انتخاب دیگری است. راهکار آماده نیز بخشی از کار مدیریت داشبورد و اعلان را بر عهده می‌گیرد.

رویکرد	نقطه قوت	مسئولیت نگهداری
فرمان‌های Linux	مشاهده سریع و دقیق سرور	تاریخچه و هشدار خودکار ندارند
Prometheus + Node Exporter	متریک و کوئری سفارشی	ذخیره‌سازی، امنیت و Alertmanager
Netdata	تحلیل زنده منابع میزبان	روش استقرار و نگهداری تاریخچه
Avaztek Monitoring	پایش منابع، سرویس و اعلان در پنل فارسی	نصب Agent و بررسی امکانات پلن

برای راهنمای تصمیم میان محصولات، مقایسه سامانه‌های مانیتورینگ سرور را ببینید. برای آشنایی با Node Exporter نیز به مستندات رسمی Prometheus رجوع کنید.

Avaztek Monitoring برای پایش VPS چه کمکی می‌کند؟

Avaztek Monitoring طبق مستندات محصول، Agent لینوکسی برای ثبت متریک‌های CPU، RAM، دیسک، شبکه و وضعیت سرویس‌ها دارد و در پنل امکاناتی برای هشدار، Log Explorer، پایش شبکه و گواهی SSL معرفی شده‌اند. برای تیمی با چند VPS، دیدن روند منابع و هشدار یکپارچه می‌تواند زمان تشخیص اختلال را کاهش دهد؛ اما لزوماً جزئیات Hypervisor یا محدودیت IOPS میزبان را نشان نمی‌دهد.

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

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

برای VPS چهار vCPU، Load Average چهار یعنی سرور خراب است؟

خیر. Load به نوع کارها و انتظار I/O نیز وابسته است. باید CPU، صف پردازش، زمان پاسخ و طول مدت وضعیت را کنار هم بررسی کرد.

Steal Time بالا در VPS به چه معناست؟

در بعضی محیط‌های مجازی به زمان انتظار پردازنده در Host اشاره می‌کند. اگر با کندی کار هم‌زمان باشد، می‌تواند نشانه محدودیت یا رقابت منابع میزبان باشد؛ مقدار آن در همه پلتفرم‌ها یکسان گزارش نمی‌شود.

آیا VPS با CPU پایین می‌تواند کند باشد؟

بله. فشار I/O، قفل دیتابیس، کمبود RAM، انتظار شبکه یا سرویس خارجی ممکن است بدون CPU بالا رخ دهد. برای تشخیص، متریک چند لایه لازم است.

چه زمانی مصرف Swap نیاز به اقدام دارد؟

وقتی فعالیت مداوم Swap In/Out با افت عملکرد، کاهش حافظه قابل دسترس یا خطای OOM همراه است. وجود مقدار استفاده‌شده در Swap به‌تنهایی نشانه بحران نیست.

آستانه هشدار مناسب برای دیسک VPS چند درصد است؟

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

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

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

جمع‌بندی: مانیتورینگ VPS را بر اساس اثر واقعی تنظیم کنید

در سرور مجازی، هم مصرف منابع مهم است و هم محدودیت مشترک میزبان. CPU، Steal Time، RAM، Swap، تأخیر دیسک، شبکه و وضعیت سرویس را در یک Timeline ببینید و هشدار را بر اساس مدت و اثر بر کاربران تعریف کنید. اگر چند VPS را مدیریت می‌کنید، Avaztek Monitoring گزینه‌ای برای ارزیابی پایش و اعلان مرکزی است.