Bối cảnh vấn đề: Đã tách riêng kênh cảnh báo critical và warning, đồng thời áp dụng nhận cuộc gọi khi có cảnh báo critical, nhưng do số lượng cảnh báo warning bùng nổ vượt quá 10.000 mỗi tháng nên xuất hiện tình trạng bỏ qua cảnh báo và mức độ mệt mỏi của trực On-call gia tăng.
Insight cốt lõi: Cảnh báo quá mức khiến hệ thống bị biến thành một health checker trên messenger, làm suy giảm khả năng quan sát hệ thống. Đề xuất đo lường 'tỷ lệ phản hồi cảnh báo' bằng emoji Slack (👀, ✅) như một chỉ số cốt lõi để cắt giảm cảnh báo.
Quá trình giải quyết:
Điều chỉnh và xóa các cảnh báo mà ý định thiết lập ban đầu không còn phù hợp với môi trường hiện tại (ví dụ: ngưỡng tăng dung lượng EBS volume không khớp).
Mạnh dạn loại bỏ những cảnh báo vô nghĩa mà không thể biết được ý đồ của người thiết lập trước đó.
Thành quả bổ sung: Sau khi loại bỏ noise cảnh báo, đã phát hiện nguyên nhân iowait cao trên một máy chủ cụ thể là do ZFS recordsize được cấu hình quá lớn so với workload thực tế và đã đưa nó về trạng thái bình thường.
Kết quả: Cảnh báo mức warning giảm 95,7% (10.553/tháng → 453/tháng). Nhận cuộc gọi critical vào đêm khuya/ngày nghỉ giảm hơn 70%. Giải quyết tình trạng thiếu ngủ khi trực On-call và cải thiện thực chất tính sẵn sàng cũng như khả năng quan sát của hệ thống.
3 bình luận
Nhật ký, chỉ số và cảnh báo là những thứ cần có thực hành điều chỉnh định kỳ.
Thấy nickname quen quen, hóa ra là người trước đây từng viết một bài thú vị về output của
cron. Bài này tôi cũng đã đọc rất hay :DCảm ơn bạn đã đọc một cách thích thú.