Cảnh báo ồn

Phần 14 đo độ trễ phát hiện. Bài này đo mặt còn lại của cùng một đánh đổi: báo giả.

Bố trí

Mô phỏng 8 giờ hoạt động, lấy mẫu mỗi 15 giây. Tỷ lệ lỗi nền 0,5%. Ba sự cố thật, mỗi cái kéo dài 10 phút với tỷ lệ lỗi 8%. Ngưỡng cảnh báo 2%.

Ngưỡng tức thời: một nửa số lần kêu là báo giả. Thêm for: 1m xoá sạch báo giả, đổi lại 45 giây chậm hơn.

Đó là toàn bộ sự đánh đổi, và nó là lý do for tồn tại.

Đáng chú ý: cách thứ tư — hai cửa sổ — không tốt hơn cách thứ hai trong kịch bản này, mà chậm hơn gấp ba. Nó chỉ có ích với sự cố cháy chậm, thứ tôi không mô phỏng. Ghi lại để không ai áp dụng nó vì nghĩ "phức tạp hơn thì tốt hơn".

Rồi đổi số yêu cầu mỗi mẫu

Cùng mọi thứ, chỉ đổi lưu lượng. Ba hạt giống cho mỗi mức:

Ở 1.000 yêu cầu mỗi mẫu, ngưỡng tức thời không báo giả lần nào — không cần for gì cả.

Ở 50 yêu cầu mỗi mẫu, cùng quy tắc đó báo giả 50 tới 53 lần cho 3 sự cố thật.

Cảnh báo ồn không phải lỗi của quy tắc cảnh báo

Nói lại lần thứ hai vì nó ngược với cách phần lớn nhóm xử lý vấn đề này: khi cảnh báo ồn, phản ứng thông thường là chỉnh quy tắc — nâng ngưỡng, tăng for, thêm điều kiện. Bảng trên cho thấy cùng một quy tắc cho 0 báo giả hoặc 53 báo giả, tuỳ vào kích thước mẫu.

Lý do là thống kê thuần tuý. Với 50 yêu cầu và tỷ lệ nền 0,5%, số lỗi kỳ vọng mỗi mẫu là 0,25. Nhưng số lỗi là số nguyên: một lỗi ngẫu nhiên đã là 2% — chạm đúng ngưỡng. Sai số của một tỷ lệ ước lượng từ n mẫu tỷ lệ với 1/√n, nên giảm n đi 20 lần thì nhiễu tăng khoảng 4,5 lần.

Và for: 1m hoạt động vì nó gộp bốn mẫu liên tiếp lại — thực chất là tăng kích thước mẫu lên bốn lần, không phải lọc gì cả.

Hệ quả: dịch vụ ít lưu lượng không cảnh báo theo tỷ lệ được

Đây là kết luận thực dụng nhất của bài.

Một dịch vụ nhận 50 yêu cầu mỗi 15 giây — khoảng 3 yêu cầu mỗi giây, hoàn toàn bình thường với dịch vụ nội bộ — không thể dùng cảnh báo dạng "tỷ lệ lỗi vượt 2%". Một lỗi đơn lẻ đã chạm ngưỡng.

Với những dịch vụ đó, cảnh báo theo số tuyệt đối:

# Sai voi dich vu it luu luong
rate(errors_total[5m]) / rate(requests_total[5m]) > 0.02

# Dung hon: doi hoi ca ty le VA so luong
rate(errors_total[5m]) / rate(requests_total[5m]) > 0.02
  and rate(requests_total[5m]) > 1

# Hoac don gian la dem
increase(errors_total[10m]) > 20

Điều kiện thứ hai ở dòng giữa là thứ hay bị quên nhất, và nó một mình giải quyết phần lớn báo giả về đêm — lúc lưu lượng thấp nhất và mẫu nhỏ nhất.

Một dạng ồn mà for không chữa được

Nhìn kỹ dòng 50 yêu cầu có for: 1m: 9 lần kêu, 9 đúng, 0 giả.

Không có báo giả, nhưng 9 lần kêu cho 3 sự cố. Cùng một sự cố kêu đi kêu lại vì tín hiệu nhấp nháy quanh ngưỡng: điều kiện đúng đủ một phút, kêu, rồi sai một nhịp, tắt, rồi đúng lại.

Đây là flapping, và nó khác báo giả: mọi cảnh báo đều đúng, chỉ là chúng lặp lại. Với người trực thì hậu quả như nhau.

for không chữa được flapping vì nó đặt lại bộ đếm mỗi khi điều kiện sai. Cách chữa là làm mượt biểu thức:

avg_over_time((rate(errors_total[5m]) / rate(requests_total[5m]))[10m:])

hoặc dùng keep_firing_for của Prometheus 2.42 trở lên — giữ cảnh báo ở trạng thái kêu thêm một khoảng sau khi điều kiện hết đúng:

- alert: TyLeLoiCao
  expr: ...
  for: 1m
  keep_firing_for: 5m

Chỗ phép đo này không nói tới

Đây là mô phỏng, không phải hệ thống thật. Sự cố của tôi là bước nhảy sạch — tỷ lệ lỗi từ 0,5% lên 8% tức thì rồi về lại. Sự cố thật thường lên dần, và với dạng đó thì cách bốn (hai cửa sổ) mới phát huy tác dụng.

Tôi cũng không mô phỏng tương quan: trong thực tế, lỗi thường đến theo cụm — một phụ thuộc chậm làm nhiều yêu cầu hỏng cùng lúc — và điều đó làm nhiễu tệ hơn giả định độc lập của tôi.

Nghĩa là con số 50 báo giả ở mức 50 yêu cầu mỗi mẫu là lạc quan, không phải bi quan.

Thử ba mươi giây

Xem cảnh báo nào của bạn đang ồn nhất:

# So lan chuyen sang keu trong 7 ngay, xep hang
sort_desc(
  count by (alertname) (
    changes(ALERTS_FOR_STATE[7d]) > 0
  )
)

# Canh bao nao dang keu ngay bay gio
ALERTS{alertstate="firing"}

# Luu luong cua dich vu — de biet mau co du lon khong
rate(http_requests_total[5m])

Lấy truy vấn cuối cùng nhân với chu kỳ quét. Nếu kết quả dưới khoảng 100 yêu cầu mỗi mẫu, mọi cảnh báo dạng tỷ lệ của dịch vụ đó đang ở vùng nhiễu của bảng trên — và cách chữa là thêm một điều kiện về số lượng, không phải nâng ngưỡng.

Phần sau: bốn tín hiệu vàng — đo trên một dịch vụ thật.