Khi website chậm hay ứng dụng treo, đoán mò không giúp được gì, bạn cần số liệu. Bài này hướng dẫn giám sát tài nguyên VPS ở ba lớp: biểu đồ có sẵn trong console Cloudj, các công cụ dòng lệnh quen thuộc trên Linux, và vài script nhỏ để nhận cảnh báo trước khi sự cố xảy ra. Cuối bài là cách quyết định khi nào nên tối ưu, khi nào nên nâng cấp cấu hình, và khi nào nên chuyển máy chủ sang vị trí khác.
Giám sát tài nguyên VPS từ biểu đồ trong console
Trang chi tiết của mỗi máy chủ trong console Cloudj có biểu đồ CPU, RAM và mạng. Đây là cách nhanh nhất để trả lời hai câu hỏi: có gì thay đổi không, và thay đổi bắt đầu từ lúc nào. Hãy xem biểu đồ trước khi SSH vào máy.
- CPU: đường gần như phẳng ở mức cao suốt nhiều giờ nghĩa là máy chủ thật sự thiếu sức xử lý. Các đỉnh ngắn khi deploy hoặc khi cron chạy là bình thường.
- RAM: mức dùng tăng đều mà không bao giờ giảm thường là dấu hiệu rò rỉ bộ nhớ hoặc một lớp cache không bị giới hạn.
- Mạng: lưu lượng gửi ra tăng đột ngột đáng để kiểm tra. Với gói tính theo giờ, băng thông được tính theo từng GB sử dụng, nên một đợt tăng bất thường cũng sẽ hiện ra trên số dư tài khoản. Gói tháng có sẵn hạn mức băng thông theo từng vị trí, bạn có thể xem trong hướng dẫn chọn vị trí VPS.
Console cho bạn biết chuyện gì đã xảy ra. Muốn biết tại sao, bạn cần vào shell. Nếu máy chủ chưa được bảo mật cơ bản, hãy làm theo checklist bảo mật VPS mới trước, để chắc rằng tải cao không đến từ một vụ dò mật khẩu SSH.
Xem tình trạng tức thời với htop
htop là công cụ dễ đọc nhất để xem máy chủ Linux theo thời gian thực. Cài đặt và chạy:
# Ubuntu / Debian
sudo apt update && sudo apt install -y htop sysstat
# AlmaLinux / Rocky Linux
sudo dnf install -y htop sysstat
htopPhần đầu màn hình có một thanh cho mỗi vCPU, mức dùng RAM và swap, cùng load average trong 1, 5 và 15 phút gần nhất. Quy tắc dễ nhớ: nếu load average 15 phút luôn cao hơn số vCPU, các tiến trình đang phải xếp hàng chờ CPU. Nhấn F6 để sắp xếp theo PERCENT_CPU hoặc PERCENT_MEM, nhấn F4 để lọc theo tên tiến trình như php-fpm hay node.
Với thanh bộ nhớ, hãy để ý hai điều: phần RAM do ứng dụng dùng so với phần làm cache, và swap có đang được dùng hay không. Linux tận dụng RAM trống làm cache cho ổ đĩa, nên RAM "gần đầy" chưa chắc là vấn đề. Swap hoạt động liên tục trong khi ứng dụng chạy chậm mới đáng lo.
Theo dõi xu hướng với vmstat
htop chỉ là ảnh chụp tại một thời điểm. vmstat in ra một dòng sau mỗi vài giây, giúp bạn thấy xu hướng rõ hơn:
vmstat 5 10Lệnh trên lấy 10 mẫu, mỗi mẫu cách nhau 5 giây. Các cột quan trọng nhất:
| Cột | Ý nghĩa | Đáng lo khi |
|---|---|---|
r | số tiến trình đang chờ chạy | thường xuyên lớn hơn số vCPU |
si / so | bộ nhớ swap vào / ra mỗi giây | thường xuyên khác 0 |
wa | thời gian CPU chờ ổ đĩa | cao đúng lúc ứng dụng chậm |
st | thời gian CPU bị hypervisor lấy | luôn cao trên gói CPU dùng chung |
id | thời gian CPU rảnh | gần 0 trong thời gian dài |
Giá trị st (steal time) cao trên gói CPU dùng chung ("Availability") nghĩa là vCPU của bạn đang phải chờ CPU vật lý. Nếu tình trạng này kéo dài và ứng dụng nặng về CPU, chuyển sang gói general purpose hoặc dedicated CPU mới là cách xử lý đúng; tối ưu code không thay đổi được con số này.
Kiểm tra I/O và dung lượng ổ đĩa
Sự cố ổ đĩa hay bị nhầm với sự cố CPU, vì tiến trình bị đứng trong lúc chờ đọc ghi. iostat nằm trong gói sysstat đã cài ở trên:
iostat -xz 5 3Hãy để ý cột %util và await của ổ đĩa chính. Mức sử dụng cao cùng thời gian chờ tăng dần nghĩa là ổ đĩa đang là nút thắt. Sau đó kiểm tra dung lượng, vì ổ đầy sẽ làm database và log hỏng theo những cách rất khó hiểu:
df -h
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20Log cũ, Docker image và file dump database thường là thủ phạm. Lệnh sudo journalctl --vacuum-size=200M thu gọn journal của systemd, còn docker system df cho biết Docker đang chiếm bao nhiêu chỗ.
Theo dõi băng thông theo từng card mạng
Để xem nhanh lưu lượng của từng interface, dùng sar (cũng thuộc gói sysstat):
sar -n DEV 5 3Muốn biết những kết nối nào đang mở và tiến trình nào sở hữu chúng:
sudo ss -tunap | head -40Nếu vấn đề nằm ở độ trễ chứ không phải băng thông, bài đo độ trễ VPS bằng ping và mtr sẽ giúp bạn kiểm tra tuyến mạng giữa người dùng và máy chủ.
Đặt cảnh báo đơn giản, không cần hệ thống giám sát lớn
Bạn không cần dựng cả một nền tảng observability chỉ để được báo động. Một script shell nhỏ chạy bằng cron đã xử lý được hai sự cố phổ biến nhất: ổ đĩa sắp đầy và RAM sắp cạn.
sudo tee /usr/local/bin/resource-check.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
DISK_LIMIT=85
MEM_LIMIT=90
disk=$(df --output=pcent / | tail -1 | tr -dc '0-9')
mem=$(free | awk '/Mem:/ {printf "%d", ($3/$2)*100}')
if [ "$disk" -ge "$DISK_LIMIT" ] || [ "$mem" -ge "$MEM_LIMIT" ]; then
logger -t resource-check "disk=${disk}% mem=${mem}%"
curl -s -X POST -H 'Content-Type: application/json' \
-d "{\"text\":\"$(hostname): disk ${disk}% mem ${mem}%\"}" \
"$ALERT_WEBHOOK_URL" > /dev/null
fi
EOF
sudo chmod +x /usr/local/bin/resource-check.shSau đó mở sudo crontab -e và đặt lịch chạy mỗi 5 phút:
ALERT_WEBHOOK_URL=https://your-chat-webhook-url
*/5 * * * * /usr/local/bin/resource-check.shWebhook có thể trỏ tới Slack, Discord, Telegram hoặc bất kỳ công cụ chat nào nhận incoming webhook. Muốn lưu lịch sử lâu dài, bạn bật thu thập nền của sysstat bằng sudo systemctl enable --now sysstat, rồi xem lại số liệu cũ bằng sar -u hoặc sar -r. Khi đã quản lý nhiều hơn một hai máy chủ, một công cụ chuyên dụng như Prometheus kết hợp node_exporter sẽ đáng công cài đặt.
Khi nào nên tối ưu, nâng cấp hay chuyển máy chủ
Giám sát chỉ có ích khi dẫn tới một quyết định. Bạn có thể đi theo thứ tự sau:
- Xử lý lãng phí trước. Một tiến trình chạy mất kiểm soát, cache không giới hạn hay database thiếu index có thể ngốn tài nguyên nhiều hơn cả lượng truy cập thật.
- Nâng cấp khi tải cao ổn định. Nếu CPU luôn ở mức cao hoặc máy chủ dùng swap hằng ngày trong điều kiện bình thường, hãy thêm tài nguyên. Trên Cloudj bạn có thể tăng CPU, RAM và mở rộng ổ đĩa ngay trong console; bài nâng cấp CPU, RAM và ổ đĩa VPS hướng dẫn các bước và những gì cần kiểm tra trước.
- Đổi loại CPU khi steal time là vấn đề. vCPU dùng chung hợp với tải lúc cao lúc thấp. Tác vụ nặng CPU liên tục nên chạy trên general purpose hoặc dedicated CPU.
- Chuyển vị trí khi vấn đề là khoảng cách. Nếu tài nguyên còn dư mà người dùng vẫn phải chờ, có thể máy chủ đang ở quá xa họ. Bài chọn vị trí VPS theo độ trễ giúp bạn cân nhắc.
Ở hầu hết vị trí, gói nhỏ nhất bắt đầu từ 1 vCPU và 1 GB RAM rồi lên tới cấu hình tùy chỉnh, nên bạn thường có thể nâng từng bước nhỏ thay vì nhảy lên một máy lớn hơn nhiều. Xem các cấu hình trên trang cloud server và giá cập nhật trên trang bảng giá.
Câu hỏi thường gặp
Bao lâu nên kiểm tra số liệu VPS một lần?
Xem biểu đồ trong console sau mỗi lần deploy và khoảng mỗi tuần một lần. Phần còn lại để script cảnh báo lo, bạn không cần ngồi canh biểu đồ cả ngày.
RAM dùng nhiều có phải lúc nào cũng xấu không?
Không. Linux dùng RAM trống làm cache cho ổ đĩa và trả lại khi ứng dụng cần. Dấu hiệu thật sự đáng lo là swap hoạt động liên tục và ứng dụng phản hồi chậm.
Steal time trên VPS là gì?
Đó là khoảng thời gian máy ảo cần CPU nhưng phải chờ. Steal time luôn cao trên gói CPU dùng chung là lý do để cân nhắc chuyển sang dedicated CPU.
Có cần cài agent để xem số liệu trong console không?
Không. Biểu đồ CPU, RAM và mạng có sẵn trên trang máy chủ trong console Cloudj. Các công cụ như htop và sysstat chỉ bổ sung thêm chi tiết từ bên trong máy.
Theo dõi đều đặn, rồi chọn cấu hình vừa đủ
Chỉ vài phút với biểu đồ console, htop, vmstat và iostat thường đủ để biết bạn cần sửa code, thêm tài nguyên hay chuyển máy chủ lại gần người dùng hơn. Khi cần nâng cấp hoặc thêm máy chủ, hãy mở console Cloudj; giá chính xác luôn hiện ra trước khi bạn triển khai.