Giám sát Dựa trên Cảnh báo: Tại sao Dashboard không phải là trọng tâm?

Các đội ngũ kỹ thuật thường liên tưởng đến khái niệm giám sát hạ tầng như một dự án để "kết nối các số liệu" (metrics) và "xây dựng bảng điều khiển" (dashboards). Trên thực tế, ở hầu hết các nền tảng giám sát, dashboard luôn là đối tượng được ưu tiên hàng đầu. Các đội thường xem đây là đầu ra chính của công việc họ. Việc nhìn thấy những hàng biểu đồ phát sáng và dữ liệu遥测 (telemetry) mang lại cảm giác rất năng suất. Chúng tạo nên những tác phẩm nghệ thuật văn phòng khá ngầu khi bạn treo chúng trên một chiếc TV khổng lồ tường nhà. Nhưng chẳng ai dành cả ngày của mình chỉ để ngồi nhìn vào những biểu đồ đó.

Trái tim thực sự của giám sát hạ tầng không phải là dashboard. Đó là các cảnh báo (alerts).

Trong khi các nền tảng khác coi cảnh báo chỉ là một bước phụ, một ô tích bạn đánh dấu sau khi hoàn thành "công việc thực sự" là trực quan hóa dữ liệu, chúng tôi tin rằng cảnh báo mới là toàn bộ mục đích của giám sát. Cảnh báo là xương sống của hoạt động vận hành hệ thống của bạn.

Bắt đầu từ sự thất bại

Khi đến lúc thiết lập cảnh báo, hầu hết các đội ngũ đều bắt đầu từ những số liệu họ đang có sẵn. Họ nhìn vào danh sách các điểm dữ liệu và tự hỏi: "Tôi có dữ liệu sử dụng CPU cho các máy chủ này rồi. Ngưỡng (threshold) nên đặt là bao nhiêu? Khoảng thời gian đánh giá nào là hợp lý?"

Đây chính xác là cách bạn kết thúc với một hệ thống ồn ào và thiếu tin cậy. Để xây dựng một hệ thống mà bạn thực sự tin tưởng, bạn phải bắt đầu từ những nguyên tắc đầu tiên.

Thay vì nhìn vào các số liệu của mình, hãy nhìn vào dịch vụ của bạn. Hãy tự hỏi bản thân: Hành vi nào thực sự cho thấy dịch vụ này đang gặp sự cố đối với người dùng? Hành vi nào dự báo rằng nó sắp gặp sự cố? Nói chung, hành vi của số liệu nào có thể chỉ ra, hoặc tốt hơn là dự đoán sự thất bại của dịch vụ?

Mẹo nhỏ Simple Observability bao gồm một danh mục các mẫu cảnh báo để giúp bạn khởi động cấu hình nhanh chóng. Mặc dù những mẫu này không được tùy chỉnh riêng cho môi trường cụ thể của bạn, nhưng chúng đóng vai trò là nền tảng tuyệt vời cho quy trình củng cố lặp lại được mô tả bên dưới.

Giai đoạn "Cậu bé chó sói"

Khi thiết lập cảnh báo, các đội ngũ thường có xu hướng thận trọng. Họ chưa biết ngưỡng tối ưu là bao nhiêu, nên họ dễ hiểu khi muốn chơi an toàn. Nhưng điều này thường dẫn đến việc tạo ra rất nhiều báo động giả.

Ban đầu, các thông báo vẫn có thể quản lý được. Nhưng sau đó, thực tế của một hệ thống trực tiếp sẽ bắt đầu tác động.

Một công việc cron chạy lúc 2:00 sáng và làm tăng vọt CPU trong ba phút. Ting ting...

Một con bot thu thập thông tin ngẫu nhiên truy cập vào một vài liên kết chết và làm tăng tỷ lệ lỗi. Ting ting...

Một bản sao lưu cơ sở dữ liệu gây ra độ trễ nhỏ tự khắc phục trong vài giây. Ting ting...

Bạn kiểm tra vài cái đầu tiên. Bạn nhận ra chúng không phải là vấn đề "thực sự". Bạn quay lại làm việc. Nhưng những tiếng ting ting không dừng lại. Chúng trở thành âm thanh vo ve đều đặn trong nền ngày của bạn mà bạn học cách bỏ qua.

Cuối cùng, kênh Slack hoặc thư mục email của bạn bị lấp đầy bởi các cảnh báo, đến mức bạn không thể phân biệt được cảnh báo nào đang kích hoạt. "Có thực sự có vấn đề gì không? Hay lại chỉ là một ngày thứ Ba bình thường khác?"

Đây chính là mệt mỏi vì cảnh báo (alert fatigue). Đó là cảm giác ập đến với các đội ngũ khi giám sát không được thiết lập đúng cách.

Vùng nguy hiểm là khi cả đội ngũ ngừng hoàn toàn việc tin tưởng vào giám sát. Đây là câu chuyện của cậu bé chó sói. Toàn bộ hệ thống thất bại vì đội ngũ ngừng tin vào nó.

Giải pháp vấn đề

Khắc phục sự mệt mỏi vì cảnh báo không phải là tìm một công thức toán học tốt hơn cho các ngưỡng của bạn. Đó là việc đưa vào các hệ thống rõ ràng, dựa trên hai nguyên tắc đơn giản sau:

Không dung thứ cho báo động giả

Nếu một cảnh báo có thể bị bỏ qua, thì nó không nên là một cảnh báo.

Cảnh báo phải có thể hành động được (actionable). Nếu không có hành động nào có thể hoặc nên được thực hiện, thì cảnh báo đó không cần thiết.

Các đội ngũ phải thực thi chính sách không dung thứ nghiêm ngặt đối với báo động giả. Nếu một cảnh báo kích hoạt và không cần hành động nào, bạn không chỉ đơn giản là bỏ qua nó. Bạn phải xóa nó, hoặc tinh chỉnh nó cho đến khi nó chỉ kích hoạt khi thực sự cần một con người can thiệp.

Cải tiến liên tục

Bạn không thể xây dựng một hệ thống giám sát hoàn hảo vào ngày đầu tiên. Bạn chưa biết mọi cách mà hạ tầng của bạn sẽ thất bại, và bạn không thể dự đoán mọi trường hợp ngoại lệ.

Thay vì cố gắng kiến trúc một hệ thống hoàn hảo ngay từ đầu, hãy thiết kế một quy trình làm cho hệ thống của bạn thông minh hơn theo thời gian. Cũng giống như bạn viết bài kiểm tra đơn vị (unit tests) để bắt các lỗi hồi quy, bạn nên coi các quy tắc cảnh báo là mã sống cần được bảo trì.

Trong thực tế, quy trình này trông như sau:

• Đánh giá hàng tuần: Các đội nên thường xuyên họp và xem xét mọi sự cố được kích hoạt bởi hệ thống giám sát.
• Cắt bỏ thường xuyên: Nếu một cảnh báo là báo động giả, hãy xóa nó ngay lập tức. Nếu nó không giúp ích gì, đó chỉ là tiếng ồn.
• Phân tích nguyên nhân gốc rễ: Nếu một sự cố thực sự xảy ra nhưng hệ thống giám sát không bắt kịp cho đến khi quá muộn, hãy thực hiện phân tích nguyên nhân gốc rễ. Số liệu nào là tín hiệu sớm nhất cho thấy sự thất bại này? Tạo một cảnh báo mới cho hành vi cụ thể đó để bạn có thể bắt nó sớm hơn vào lần tới.

Cũng giống như bạn sử dụng bài kiểm tra đơn vị để củng cố mã của mình, bạn sử dụng chu trình này để củng cố giám sát một cách lặp lại. Mục tiêu của bạn là làm cho các quy tắc cảnh báo trở nên mạnh mẽ hơn mỗi tuần, đồng thời giảm tổng số sự cố.

Bằng cách thúc đẩy hệ thống lặp lại này như một đội ngũ, bạn biến cảnh báo thành một phần cốt lõi của văn hóa kỹ thuật của mình.