Đặt ngưỡng cảnh báo CPU, RAM, ổ đĩa bao nhiêu là hợp lý?

Đặt ngưỡng cảnh báo là bài toán cân bằng giữa hai cái giá: báo muộn thì sự cố thành downtime, báo bừa thì người trực học cách bỏ qua thông báo, và đến cảnh báo thật cũng bị bỏ qua nốt. Hiện tượng thứ hai có tên hẳn hoi, alert fatigue, và nó giết nhiều hệ thống giám sát hơn là thiếu tính năng. Bài này đưa con số khởi điểm theo từng loại workload và hai kỹ thuật chống báo động giả.

Ngưỡng khuyến nghị theo loại workload là bao nhiêu?

Không có ngưỡng đúng cho mọi máy, vì “bình thường” của web server khác hẳn “bình thường” của database hay CI runner. Bảng dưới là điểm khởi đầu an toàn, sau 2-4 tuần nhìn biểu đồ thực tế bạn nên chỉnh lại theo đường nền của chính mình:

Chỉ số	Web / app server	Database	CI runner / batch
CPU	Trên 85% kéo dài 5 phút	Trên 80% kéo dài 5 phút	Trên 95% kéo dài 30-60 phút
RAM (theo available)	Available dưới 10%	Available dưới 5%, kèm theo dõi swap	Available dưới 10%
Swap	Dùng trên 20% và còn tăng	Có swap-in liên tục là báo ngay	Ít quan trọng, trừ khi job treo
Ổ đĩa (dung lượng)	Trên 85%	Trên 80%	Trên 90%, dọn được bằng cache
Ổ đĩa (inode)	Trên 85%	Trên 85%	Trên 85%

Vì sao mỗi loại máy một ngưỡng khác nhau?

Web và app server phục vụ người dùng trực tiếp, nên thứ bạn thật sự bảo vệ là độ trễ. CPU vượt khoảng 85% kéo dài đồng nghĩa request bắt đầu xếp hàng và thời gian phản hồi tăng phi tuyến. Khoảng đệm 15% còn lại là thời gian để bạn kịp phản ứng trước khi người dùng cảm nhận được.

Database ăn RAM theo thiết kế: MySQL với InnoDB buffer pool hay PostgreSQL với shared buffers sẽ chiếm phần lớn bộ nhớ, và phần “trống” còn lại được kernel dùng làm page cache. Vì vậy nhìn cột used của free -m sẽ thấy RAM lúc nào cũng gần đầy, và đó là điều tốt. Chỉ số đúng để canh là available và swap: available tụt sâu cộng swap-in liên tục nghĩa là cache đang bị đẩy ra đĩa, hiệu năng truy vấn sắp rơi tự do. Ngưỡng đĩa của database cũng chặt hơn (80%) vì hết đĩa giữa chừng là kịch bản hỏng dữ liệu, không chỉ là downtime.

CI runner và máy batch thì ngược đời: CPU 100% là trạng thái làm việc đúng nghĩa. Đặt ngưỡng “CPU trên 85%” cho máy build là tự tay chế tạo máy phát báo động giả. Với loại máy này, tín hiệu đáng báo là thời lượng: CPU ghim 95-100% suốt 30-60 phút thường nghĩa là job treo hoặc vòng lặp vô hạn, chứ không phải build đang chạy.

Riêng ổ đĩa có một đặc tính khiến nó nguy hiểm hơn CPU và RAM: nó không tự hồi phục. CPU xong việc thì tụt, RAM giải phóng thì hồi, còn đĩa chỉ có tăng cho đến khi có người dọn. Vì vậy cảnh báo đĩa ở 85% không phải “sắp có sự cố” mà là “đặt lịch dọn dẹp trong tuần này”. Nếu đĩa của bạn tăng 1% mỗi ngày, ngưỡng 85% cho bạn 2 tuần chuẩn bị; ngưỡng 95% chỉ cho 5 ngày.

Hysteresis là gì và vì sao thiếu nó là thảm họa?

Tưởng tượng CPU dao động quanh 84-86% suốt một giờ, còn ngưỡng của bạn là 85%. Không có hysteresis, hộp thư của bạn sẽ nhận được chuỗi “CẢNH BÁO… ĐÃ HỒI PHỤC… CẢNH BÁO… ĐÃ HỒI PHỤC” vài chục lần. Đây gọi là cảnh báo flapping.

Hysteresis xử lý bằng cách tách hai ngưỡng:

Ngưỡng phát cảnh báo:  CPU > 85%
Ngưỡng xác nhận hồi phục: CPU < 75%

84% -> 87% : phát cảnh báo (vượt 85)
87% -> 81% : vẫn giữ trạng thái cảnh báo (chưa xuống dưới 75)
81% -> 86% : không phát thêm gì (đang trong trạng thái cảnh báo sẵn)
86% -> 72% : phát thông báo hồi phục (đã xuống dưới 75)

Khoảng đệm 10 điểm phần trăm giữa hai ngưỡng biến hàng chục thông báo nhiễu thành đúng 2 thông báo có nghĩa: một lúc bắt đầu, một lúc kết thúc.

Cần bao nhiêu mẫu liên tiếp mới nên báo?

Kỹ thuật chống nhiễu thứ hai: đừng báo ngay ở mẫu vượt ngưỡng đầu tiên. Một cron job nặng chạy 40 giây có thể đẩy CPU lên 95% đúng lúc hệ thống lấy mẫu, rồi mọi thứ về bình thường. Báo cho tình huống đó là báo bừa.

Quy tắc thực dụng: yêu cầu 3 mẫu liên tiếp vượt ngưỡng. Độ trễ phát hiện khi đó bằng số mẫu nhân chu kỳ thu thập:

Chu kỳ thu thập	2 mẫu liên tiếp	3 mẫu liên tiếp	5 mẫu liên tiếp
30 giây	1 phút	1,5 phút	2,5 phút
1 phút	2 phút	3 phút	5 phút
5 phút	10 phút	15 phút	25 phút

Chọn theo mức chịu đựng của dịch vụ: website bán hàng nên phát hiện trong dưới 3 phút, còn máy chạy báo cáo nội bộ thì 15 phút cũng không ai thiệt. Lưu ý dòng cuối bảng: với chu kỳ 5 phút, đòi 5 mẫu nghĩa là gần nửa tiếng sau bạn mới biết chuyện. Chu kỳ càng thưa thì số mẫu yêu cầu nên càng ít.

Triển khai các ngưỡng này thế nào cho nhanh?

Nếu tự dựng, cả Zabbix lẫn Prometheus đều hỗ trợ hysteresis và điều kiện thời lượng, nhưng bạn phải tự cấu hình từng rule. Nếu muốn có ngay, các dịch vụ giám sát có agent thường làm sẵn phần khó: với AgentWatch, agent thu CPU, RAM, đĩa theo chu kỳ, bạn đặt ngưỡng và số mẫu liên tiếp trên dashboard, cảnh báo đi qua Zalo hoặc email. Gói Free cho 2 server ở chu kỳ 5 phút, đủ để bắt đầu đo đường nền trước khi tinh chỉnh ngưỡng.

Điều cuối cùng, và quan trọng nhất: ngưỡng không phải thứ đặt một lần rồi quên. Mỗi tháng, mở biểu đồ ra và hỏi hai câu. Có cảnh báo nào tháng qua mà bạn đã bỏ qua không xử lý không? Xóa hoặc nới nó. Có sự cố nào xảy ra mà không có cảnh báo nào báo trước không? Thêm ngưỡng cho đúng chỉ số đó. Hệ thống cảnh báo tốt là hệ thống mà mọi thông báo đều đáng để dừng việc đang làm.