Khi tìm kiếm cách đặt cảnh báo tài nguyên máy chủ, bạn sẽ rất dễ bắt gặp một công thức quen thuộc: CPU chạm 80% thì báo động, RAM lên 90% thì gửi tin nhắn, ổ đĩa đầy 85% thì bật còi. Những con số tròn trịa này nghe rất thuận tai và dễ nhớ, nên nhiều người thường bê nguyên xi vào cấu hình giám sát.
Nhưng khi đưa vào vận hành thật, công thức này bắt đầu bộc lộ vấn đề. Cứ đúng 2h sáng khi script backup nén dữ liệu, CPU vọt lên 95% trong 3 phút rồi hạ xuống, điện thoại lại rung chuông inh ỏi dù website lúc đó không một bóng người truy cập và chẳng có lỗi nào phát sinh. Ngược lại, có những hệ thống RAM "đã dùng" chạm 92% nhưng ứng dụng vẫn phản hồi nhanh thoăn thoắt vì phần lớn là bộ nhớ đệm cache hệ điều hành tự quản lý; trong khi có máy chủ ổ đĩa mới dùng 60% nhưng thư mục session đã phình to hàng triệu file nhỏ khiến hệ thống hết sạch Inode và đột ngột tê liệt.
Cảnh báo tài nguyên máy chủ không thể chỉ dựa vào một con số phần trăm cứng nhắc. Một ngưỡng cảnh báo thực tế và có giá trị hành động cần kết hợp được cả mức hoạt động bình thường (baseline), thời gian duy trì, tốc độ tiêu hao và trải nghiệm thực tế của người dùng.
Ngưỡng chỉ có ý nghĩa khi đi cùng baseline, thời lượng, tác động và hành động đã định trước.
Xác định baseline: Máy chủ của bạn chạy bình thường trông ra sao?
Trước khi quyết định con số nào là "bất thường", bạn cần biết hệ thống khi chạy bình thường sẽ có biểu hiện thế nào. Mỗi website có một đặc thù riêng: một trang tin tức có lượng đọc ổn định ban ngày sẽ rất khác một trang thương mại điện tử chuyên chạy flash sale vào buổi tối, và càng khác một ứng dụng nội bộ chỉ có nhân viên truy cập trong giờ hành chính.
Cách tốt nhất là để công cụ giám sát thu thập dữ liệu trong ít nhất 7 ngày đầu tiên mà chưa cần bật cảnh báo làm phiền ai. Khoảng thời gian một tuần này sẽ cho bạn thấy trọn vẹn:
- Nhịp sinh hoạt của người dùng: Giờ nào vắng khách, giờ nào cao điểm nhất trong ngày, cuối tuần traffic tăng hay giảm.
- Lịch trình của các tác vụ định kỳ: Giờ chạy backup, giờ chạy cron job đồng bộ dữ liệu hoặc gửi email bản tin.
- Mức tiêu hao tài nguyên thông thường: Ngày thường CPU ăn bao nhiêu %, khi cao điểm chạm mốc nào, RAM khả dụng còn lại bao nhiêu.
- Mức tăng tự nhiên của ổ đĩa: Mỗi ngày cơ sở dữ liệu và file upload tăng thêm khoảng bao nhiêu megabyte.
Sau khi nắm được các mốc này, bạn sẽ nhận ra ngưỡng nào là an toàn cho riêng máy chủ của mình, thay vì áp dụng một quy chuẩn chung chung từ nơi khác.
Để có cái nhìn tổng quan về các lớp giám sát trước khi tinh chỉnh sâu vào từng thông số, bạn có thể xem lại bài Nên monitoring những gì trên một VPS chạy website?.
Đặt ngưỡng cảnh báo CPU: Quan sát thời lượng và độ trễ
Chỉ số CPU utilization đo lường tỷ lệ thời gian vi xử lý bận rộn xử lý tác vụ thay vì ở trạng thái rảnh rỗi. Bản thân con số này không nói lên việc website có đang chạy chậm hay không.
Khi thiết lập cảnh báo cho CPU, bạn cần kết hợp 3 yếu tố sau:
1. Thời lượng duy trì (Duration)
Đừng bao giờ gửi cảnh báo ngay khi CPU vừa chạm một mốc nào đó trong 10 hoặc 30 giây. Máy chủ thỉnh thoảng có những đợt tăng vọt ngắn hạn khi import dữ liệu hoặc nén log là chuyện bình thường. Hãy đặt điều kiện: CPU phải duy trì trên ngưỡng cảnh báo liên tục từ 5 đến 15 phút thì mới phát thông báo.
2. Đi kèm với độ trễ (Latency) hoặc mã lỗi (Error Rate)
Một hệ thống có CPU chạm 85% nhưng thời gian phản hồi trang web vẫn dưới 300 ms thì có nghĩa là máy chủ đang tận dụng rất tốt sức mạnh phần cứng mà bạn bỏ tiền ra thuê. Ngược lại, nếu CPU chỉ 60% nhưng website văng lỗi 504 Gateway Timeout hoặc độ trễ nhảy vọt lên 5 giây, đó mới là lúc bạn cần can thiệp gấp. Cảnh báo khẩn cấp nhất nên gắn liền với trải nghiệm của người dùng.
3. Phân biệt CPU % và Load Average
Nhiều người nhìn thấy Load Average trên Linux hiển thị con số 8 trên một VPS chỉ có 2 core CPU thì hốt hoảng nghĩ máy chủ sắp cháy. Thực tế, Load Average đo cả số tiến trình đang chờ CPU lẫn các tiến trình đang bị nghẽn chờ đọc ghi ổ đĩa (I/O Wait). Nếu CPU % rất thấp nhưng Load Average lại cao vút, vấn đề thường không nằm ở thuật toán hay code mà do ổ đĩa đang bị quá tải.
Khi CPU thực sự chạm đỉnh 100% kéo dài, bài viết VPS CPU 100%: Cách tìm tiến trình gây tải mà không vội reboot sẽ hướng dẫn bạn các lệnh thực tế để tóm đúng tiến trình đang ngốn chip.
Đặt ngưỡng cảnh báo RAM: Nhìn vào MemAvailable và Swap
Đây là nơi xảy ra nhiều cảnh báo giả nhất trên hệ thống Linux. Cơ chế quản lý bộ nhớ của nhân Linux luôn tận dụng tối đa lượng RAM nhàn rỗi để làm bộ đệm (Buff/Cache) giúp việc đọc file nhanh hơn. Khi ứng dụng cần thêm RAM, hệ điều hành sẽ tự động thu hồi lượng cache này lại để cấp phát.
Nếu bạn cấu hình cảnh báo dựa trên công thức (RAM tổng - RAM rảnh) / RAM tổng, hệ thống của bạn gần như lúc nào cũng ở trạng thái báo động 85%–90%.
Thay vào đó, bạn nên theo dõi 2 chỉ số thực chất hơn:
- MemAvailable (RAM thực sự khả dụng): Đây là con số do chính nhân Linux ước tính về lượng bộ nhớ có thể cấp phát ngay cho ứng dụng mới mà không cần đẩy dữ liệu cũ sang ổ đĩa (swap). Bạn có thể đặt cảnh báo mức Nhắc nhở (Warning) khi MemAvailable duy trì dưới mức 20%–25%, và mức Nguy cấp (Critical) khi con số này tụt xuống dưới 10%–15%.
- Hoạt động của Swap: Swap là vùng nhớ trên ổ cứng dùng để cứu nguy khi RAM thật cạn kiệt. Nếu Swap chỉ lưu một ít dữ liệu cũ ít dùng thì không đáng ngại. Nhưng nếu bạn thấy hệ thống liên tục ghi đọc dữ liệu ra vào Swap (Swap I/O tăng vọt), máy chủ sẽ chậm đi thấy rõ và rất dễ kích hoạt cơ chế OOM Killer (nhân Linux tự động tắt tiến trình ngốn RAM nhất để cứu hệ điều hành).
Để hiểu rõ cách xử lý khi máy chủ bị cạn kiệt bộ nhớ và tránh bị OOM Killer tắt mất database, bạn có thể xem bài VPS hết RAM và OOM Killer: Dấu hiệu, kiểm tra và phòng ngừa.
Đặt ngưỡng cảnh báo Disk: Kết hợp dung lượng, Inode và tốc độ đầy
Ổ đĩa là loại tài nguyên mà khi cạn kiệt sẽ gây hậu quả tức thì và nặng nề nhất: database dừng đột ngột dễ làm hỏng file dữ liệu, log không ghi được và phiên làm việc của người dùng bị hủy bỏ.
Khi đặt cảnh báo cho ổ đĩa, hãy kết hợp cả 3 góc nhìn:
1. Số gigabyte còn lại thay vì chỉ nhìn phần trăm
Ngưỡng 15% còn trống nghe có vẻ nhỏ, nhưng trên một ổ đĩa 1 TB thì nó tương đương 150 GB — đủ chỗ chạy thoải mái trong nhiều tháng. Tuy nhiên, nếu VPS của bạn chỉ có ổ cứng 25 GB, 15% chỉ còn chưa đầy 4 GB. Một đợt backup dữ liệu hoặc một file log quay vòng không đúng cách có thể nuốt trọn 4 GB này chỉ sau vài giờ. Vì vậy, ngoài phần trăm (ví dụ cảnh báo ở mức 80% và 90%), hãy đặt thêm ngưỡng dung lượng tối thiểu tuyệt đối: ví dụ cảnh báo ngay nếu dung lượng trống dưới 5 GB.
2. Tốc độ tiêu hao (Burn Rate)
Thay vì chờ ổ đĩa chạm mức 85% mới biết, các công cụ giám sát hiện đại (như Prometheus với hàm dự báo) có thể tính toán tốc độ tăng trưởng của dữ liệu. Nếu ổ đĩa mới dùng 65% nhưng trong 3 tiếng vừa qua mỗi tiếng bị mất thêm 3 GB, công cụ sẽ gửi ngay cảnh báo: "Với tốc độ này, ổ đĩa sẽ đầy trong vòng 6 giờ tới". Cảnh báo theo tốc độ tiêu hao giúp bạn có cả nửa ngày để dọn dẹp thay vì bị đánh thức lúc nửa đêm khi ổ đĩa đã chạm 99%.
3. Đừng quên số lượng Inode
Mỗi file được tạo ra trên Linux sẽ tiêu tốn một Inode. Nếu website của bạn dùng framework sinh ra quá nhiều file cache nhỏ hoặc session không được dọn dẹp, Inode có thể chạm ngưỡng 100% trong khi dung lượng ổ đĩa vẫn còn trống một nửa. Lúc này máy chủ cũng không thể tạo thêm bất kỳ file nào mới. Hãy đặt ngưỡng cảnh báo Inode tương tự như dung lượng: nhắc nhở ở mức 80% và nguy cấp ở mức 90%.
Nếu ổ đĩa máy chủ bất ngờ tăng đột biến, bạn có thể tham khảo quy trình khoanh vùng thư mục phình to tại bài VPS đầy ổ đĩa: Nguyên nhân, dấu hiệu và cách phòng ngừa.
Phân cấp cảnh báo: Warning và Critical phải khác nhau ở hành động
Một sai lầm rất tai hại là gán mức độ ưu tiên theo kiểu: 80% là Warning, 90% là Critical nhưng cả hai đều bắn tin nhắn kêu chuông ầm ĩ vào cùng một nhóm chat Telegram. Người trực ca sẽ nhanh chóng bị chai lỳ cảm giác nguy cấp.
Hai mức độ này phải khác nhau hoàn toàn về thời hạn xử lý và kênh nhận tin:
| Mức độ cảnh báo | Tình trạng hệ thống | Kênh thông báo | Hành động cần làm |
|---|---|---|---|
| Nhắc nhở (Warning) | Tài nguyên hao hụt nhưng website vẫn chạy tốt; còn nhiều giờ hoặc vài ngày trước khi có rủi ro. | Nhóm chat thông báo nội bộ, kênh Slack/Discord, hoặc tạo ticket công việc. | Xử lý trong giờ hành chính: lên kế hoạch dọn dẹp log, tối ưu câu truy vấn, hoặc tính phương án nâng cấp gói VPS. |
| Nguy cấp (Critical) | Người dùng đang gặp lỗi, hoặc tài nguyên sắp cạn kiệt trong vòng 1–2 giờ tới. | Bắn tin nhắn trực tiếp, bật chuông kênh khẩn cấp hoặc gọi điện tự động. | Cần người vào xử lý ngay lập tức theo quy trình ứng cứu sự cố để tránh sập hệ thống. |
Cách phân chia kênh tin và lọc nhiễu cảnh báo được trình bày rất chi tiết trong bài Thiết kế cảnh báo có thể hành động.
Bảng gợi ý cấu hình ngưỡng ban đầu cho VPS
Nếu bạn chưa biết bắt đầu từ con số nào, đây là bộ khung thực tế để bạn cài đặt thử nghiệm cho một VPS thông thường, sau đó điều chỉnh dần theo baseline thực tế:
| Thành phần | Ngưỡng Nhắc nhở (Warning) | Ngưỡng Nguy cấp (Critical) | Thời gian duy trì cần kiểm tra |
|---|---|---|---|
| CPU Usage | Duy trì trên 75% | Duy trì trên 90% kèm thời gian phản hồi web tăng | Kiểm tra liên tục trong 10 đến 15 phút |
| RAM (MemAvailable) | Thấp hơn 25% tổng RAM | Thấp hơn 10%–15% tổng RAM hoặc Swap bị ghi đọc liên tục | Duy trì trong 5 đến 10 phút |
| Dung lượng Ổ đĩa | Dùng trên 80% hoặc trống dưới 10 GB | Dùng trên 90% hoặc trống dưới 3 GB, hoặc dự báo đầy dưới 12h | Kiểm tra theo chu kỳ 15 đến 30 phút |
| Inode Ổ đĩa | Dùng trên 80% tổng Inode | Dùng trên 90% tổng Inode | Kiểm tra theo chu kỳ 1 đến 2 giờ |
Rà soát lại ngưỡng sau mỗi lần thay đổi hệ thống
Bộ ngưỡng bạn đặt hôm nay không thể cố định mãi mãi. Mỗi khi hệ thống có những biến chuyển lớn, bạn cần dành thời gian quan sát lại baseline:
- Khi nâng cấp cấu hình VPS: Một máy chủ nâng từ 2 Core lên 4 Core, hoặc nâng RAM từ 4 GB lên 8 GB sẽ có hành vi tiêu hao tài nguyên và dư địa đệm hoàn toàn khác trước.
- Khi triển khai tính năng mới hoặc đổi kiến trúc: Chuyển từ chạy trực tiếp sang đóng gói container, thêm queue worker, hay tích hợp thêm dịch vụ tìm kiếm Elasticsearch sẽ làm thay đổi mức ngốn RAM và CPU thông thường.
- Khi có chiến dịch marketing: Lượng truy cập tăng gấp 3–4 lần vào dịp lễ là điều đã dự liệu trước. Nếu không điều chỉnh tạm thời hoặc chuẩn bị tài nguyên, cảnh báo sẽ réo chuông liên tục dù hệ thống vẫn đang gồng gánh tốt.
Mục tiêu của việc đặt ngưỡng cảnh báo không phải là để khoe một dashboard lúc nào cũng xanh rì không tì vết. Mục tiêu thực sự là khi có bất kỳ dòng tin nhắn nào phát ra, bạn biết chắc chắn rằng đó là việc đáng để mở máy tính lên xử lý, và bạn có đủ thời gian hành động trước khi sự cố chạm tới khách hàng.
Checklist thiết lập cảnh báo tài nguyên
- ☐ Đã theo dõi baseline của máy chủ trong ít nhất 7 ngày trước khi bật cảnh báo chính thức.
- ☐ Cảnh báo CPU có cài đặt thời gian duy trì (tối thiểu 5–10 phút), không bắt theo các đợt tăng vọt ngắn hạn.
- ☐ Theo dõi bộ nhớ dựa trên chỉ số
MemAvailablevà hoạt động của Swap, không dùng công thức RAM đã cấp phát đơn thuần. - ☐ Cảnh báo ổ đĩa kết hợp cả phần trăm, số gigabyte trống tối thiểu và kiểm tra số lượng Inode.
- ☐ Phân định rạch ròi giữa cảnh báo Nhắc nhở (xử lý giờ hành chính) và cảnh báo Nguy cấp (phải can thiệp ngay).
- ☐ Mỗi tin nhắn cảnh báo đều ghi rõ tên máy chủ, chỉ số bị vượt ngưỡng và đường dẫn tới dashboard kiểm tra.
- ☐ Có kế hoạch rà soát lại ngưỡng cảnh báo mỗi khi nâng cấp gói VPS hoặc cập nhật phiên bản ứng dụng lớn.
