[Microservices Series] Bài 14: Monitoring & Alerting – Chống "mù" hệ thống và nghệ thuật gọi điện dựng đầu lúc nửa đêm

Chào anh em, mình đây! Ở bài 13, chúng ta đã gỡ được cục nợ file .env bằng cấu hình tập trung. Hệ thống lúc này đã chạy ro ro trên server, khách hàng bắt đầu sử dụng. Bạn tắt máy, lên giường đi ngủ với một nụ cười mãn nguyện.

Đến 8h sáng hôm sau lên công ty, sếp gọi bạn vào phòng chỉ mặt: "Hệ thống sập từ 3h sáng, khách hàng chửi ầm ĩ trên fanpage mà team Dev không ai biết gì à?".

Trong Monolith, khi app tạch, user báo lỗi, bạn vào server xem log là xong. Nhưng ở Microservices, lỗi không xuất hiện ngay lập tức. Service Cổng soát vé (Gate) có thể bị tràn bộ nhớ dần dần (Memory Leak) từ 1h sáng, chạy chậm rì rì, kéo theo Service Thanh toán bị timeout, và đến 3h sáng thì toàn bộ hệ thống "đột quỵ".

Để không bao giờ rơi vào thảm cảnh khách hàng biết lỗi trước Dev, chúng ta bắt buộc phải xây hệ thống Monitoring (Giám sát) và Alerting (Cảnh báo). Cặp bài trùng "quốc dân" cho việc này chính là Prometheus & Grafana.

1. Prometheus – Kẻ thu thập những "Nhịp đập" hệ thống

Nhiều anh em nhầm tưởng Monitoring là thi thoảng viết một đoạn code ping vào URL xem service còn trả về HTTP 200 hay không. Đó chỉ là kiểm tra hộp đen (Blackbox). Trong Microservices, chúng ta cần nhìn thấu vào "lục phủ ngũ tạng" của từng service (Whitebox).

Thay vì để các service tự chủ động đẩy cục dữ liệu hiệu năng đi (Push model - rất tốn tài nguyên), Prometheus sử dụng Pull model.

Mỗi service (dù viết bằng Go, Nodejs hay Laravel) sẽ mở một endpoint bí mật, ví dụ /metrics. Bên trong đó phơi bày toàn bộ chỉ số hiện tại: Đang ăn bao nhiêu MB RAM, CPU load bao nhiêu %, có bao nhiêu Goroutines đang chạy, số lượng query đang kẹt ở PostgreSQL là bao nhiêu. Cứ đúng 15 giây một lần, máy chủ Prometheus sẽ tự động "đi tuần" qua hàng chục IP của các container, cào (scrape) cái đống metrics đó về và lưu vào một Time-series Database (Cơ sở dữ liệu chuỗi thời gian) siêu tốc của nó. Các service nghiệp vụ hoàn toàn rảnh rang, không tốn chút sức lực nào cho việc báo cáo.

2. Grafana – Bảng điều khiển "Triệu đô"

Prometheus thu thập dữ liệu rất giỏi, nhưng nó lưu dưới dạng text thô rất khó đọc. Đây là lúc Grafana vào việc.

Grafana móc nối vào Prometheus và vẽ ra những biểu đồ tuyệt đẹp. Thay vì nhìn vào những dòng số vô hồn, bạn có một Dashboard (Bảng điều khiển) cực kỳ trực quan:

• Biểu đồ đường (Line chart) màu xanh hiển thị CPU của Service Bán vé đang êm đềm ở mức 10%.

• Một cái đồng hồ đo (Gauge) đỏ chót báo động RAM của Redis đã đầy 95%.

• Một biểu đồ cột đếm chính xác số lượng lỗi HTTP 500 xuất hiện trong 5 phút qua.

Khi có Grafana, team vận hành có thể cắm một cái màn hình siêu to khổng lồ giữa văn phòng. Bất kỳ một vạch đỏ nào nhô lên bất thường, cả team sẽ phát hiện ra ngay lập tức chỉ bằng một cái liếc mắt.

3. Thực chiến Alerting tại hệ thống AFC

Phát hiện bằng mắt lúc làm việc là chưa đủ. Ban đêm không ai ngồi nhìn màn hình Grafana cả. Tại hệ thống AFC của tuyến Metro số 1, mình thiết lập một bộ quy tắc Alerting (Cảnh báo) cực kỳ khắt khe thông qua Alertmanager.

Mình không cảnh báo dựa trên nguyên nhân sâu xa (kiểu CPU cao), mà cảnh báo dựa trên Triệu chứng ảnh hưởng đến người dùng (Symptom-based Alerting).

Ví dụ: Tại các máy bán vé tự động (TVM), nếu hành khách nạp tiền mà thời gian chờ (Response Time) vượt quá 3 giây.

• Phút thứ 1: Grafana ghi nhận Response Time tăng lên 3.5 giây. Hệ thống vẫn im lặng theo dõi.

• Phút thứ 3: Nếu tình trạng vẫn tiếp diễn, Alertmanager kích hoạt Cảnh báo Vàng. Một tin nhắn tự động bắn thẳng vào group Telegram của team Backend: "[Warning] TVM Topup Service đang phản hồi chậm (>3s). Đề nghị kiểm tra."

• Phút thứ 5: Lỗi leo thang, tỷ lệ quẹt thẻ lỗi qua cửa (Gate Service) tăng vượt mức 5%. Lập tức kích hoạt Cảnh báo Đỏ. Alertmanager kích hoạt cuộc gọi điện thoại tự động (qua PagerDuty hoặc Twilio) thẳng vào máy cá nhân của trực ban, kêu gào đến khi nào có người bấm nút "Acknowledge" (Đã nhận) thì thôi.

Nhờ kịch bản này, team luôn vào server xử lý, tắt bớt các tiến trình kẹt, hoặc scale up hệ thống trước khi đám đông hành khách bắt đầu nhận ra sự chậm trễ.

Lời khuyên "xương máu" về Alert Fatigue (Hội chứng mệt mỏi vì cảnh báo)

Sai lầm lớn nhất của các anh em mới làm Monitoring là Cảnh báo quá nhiều thứ rác. CPU vọt lên 80% trong 10 giây? Báo động! RAM đầy 70%? Báo động! Hậu quả là một đêm group Telegram nổ 500 cái tin nhắn. Đến ngày thứ 3, não bộ của anh em Dev sẽ tự động hình thành cơ chế... bỏ qua mọi thông báo từ bot. Đến lúc hệ thống chết thật, ai cũng nghĩ là "chắc con bot lại lag đấy".

Hãy nhớ quy tắc Vàng: Chỉ réo tên Dev vào nửa đêm khi và chỉ khi Khách hàng không thể thực hiện được nghiệp vụ cốt lõi, hoặc hệ thống mất tiền. Còn lại (CPU cao nhưng app vẫn chạy, 1 trong 3 node Database phụ bị rớt mạng), hãy gửi một email nhẹ nhàng để sáng mai đến công ty xử lý.

Giám sát xong rồi, bắt được lỗi rồi, nhưng làm sao để hệ thống có thể "tự chữa lành" và tăng tốc phục vụ dữ liệu liên tục mà không cần chọc vào Database chính quá nhiều?

Ở bài tiếp theo (Bài 15), chúng ta sẽ trang bị một vũ khí tối thượng về hiệu năng: Caching phân tán với Redis – Tấm khiên thép bảo vệ Database mùa cao điểm.

Anh em đã bao giờ bị hệ thống dựng đầu dậy lúc 3h sáng chưa? Cảm giác lúc đó luống cuống tìm log thế nào? Cùng chia sẻ dưới comment nhé!