Alert theo triệu chứng là cảnh báo dựa trên thứ người dùng cảm nhận: tỉ lệ lỗi, độ trễ, không đặt được đơn. Alert theo nguyên nhân dựa trên trạng thái nội bộ: CPU > 80%, số pod giảm, cache miss tăng.
Ba vấn đề của alert theo nguyên nhân:
1. Báo động giả. CPU 90% trong đợt xử lý theo lô là bình thường, người dùng không thấy gì. Đánh thức người trực để rồi kết luận "vẫn ổn" là cách nhanh nhất tạo ra thói quen bỏ qua cảnh báo.
2. Bỏ sót. Danh sách nguyên nhân là vô hạn. Sự cố lần sau đến từ một nguyên nhân chưa ai nghĩ tới, và không có rule nào bắt được — trong khi triệu chứng thì luôn giống nhau: người dùng gặp lỗi hoặc phải chờ.
3. Nhiễu khi có sự cố thật. Một nguyên nhân gốc kích hoạt hàng chục rule nguyên nhân cùng lúc, người trực phải lọc thay vì xử lý.
Ví dụ: thay vì mysql_connections > 900, hãy alert tỉ lệ 5xx của /checkout > 1% trong 10 phút. Số kết nối cao mà đơn vẫn đặt được thì không cần ai thức dậy; còn nếu đơn hỏng vì lý do khác hẳn (bug ở code mới, cổng thanh toán chết), alert triệu chứng vẫn nổ đúng lúc.
Nguyên nhân thì đặt ở đâu: đưa vào dashboard và runbook, hoặc alert mức ticket không paging. Chúng dùng để chẩn đoán sau khi triệu chứng đã đánh thức người trực.
Ngoại lệ hợp lý là các cảnh báo sắp cạn có thời gian phản ứng dài: đĩa sẽ đầy trong 4 giờ, chứng chỉ TLS hết hạn sau 14 ngày — chưa có triệu chứng nhưng chắc chắn sẽ có, và xử lý trước rẻ hơn nhiều.