Cách xây dựng hệ thống monitoring giám sát ứng dụng production

Hệ thống monitoring giám sát ứng dụng production giúp đội kỹ thuật biết hệ thống có đang phục vụ người dùng tốt không, và nếu không thì hỏng ở đâu, trước khi khách hàng phải gọi điện báo. Một hệ thống hiệu quả cần đo đúng chỉ số phản ánh trải nghiệm người dùng, đặt mục tiêu chất lượng dịch vụ rõ ràng, cảnh báo khi mục tiêu bị đe dọa và có quy trình phản ứng khi sự cố xảy ra. Công cụ (Prometheus, Grafana hay dịch vụ cloud) là phần dễ; chọn đo cái gì và cảnh báo khi nào mới là phần khó.

Monitoring và observability

Monitoring trả lời câu hỏi đã biết trước: CPU có cao không, tỷ lệ lỗi có vượt ngưỡng không. Observability (khả năng quan sát) là khả năng trả lời câu hỏi chưa biết trước bằng dữ liệu hệ thống phát ra: vì sao chỉ khách hàng dùng một ngân hàng cụ thể bị lỗi thanh toán từ 9 giờ sáng. Observability dựa trên ba loại dữ liệu:

• Metrics: số đo theo thời gian (số request mỗi giây, độ trễ, bộ nhớ). Rẻ, hợp để cảnh báo và vẽ xu hướng.
• Logs: bản ghi sự kiện chi tiết. Hợp để điều tra nguyên nhân; xem thêm bài xây dựng hệ thống logging tập trung.
• Traces: đường đi của một request qua nhiều service, cho biết thời gian tiêu tốn ở từng bước.

Bài này tập trung vào metrics và cảnh báo, phần nền tảng của monitoring.

Đo cái gì: các phương pháp kinh điển

Bốn tín hiệu vàng

Cuốn sách Site Reliability Engineering của Google đề xuất bốn tín hiệu cho mọi hệ thống hướng người dùng: độ trễ (latency), lưu lượng (traffic), lỗi (errors) và độ bão hòa (saturation, mức độ "đầy" của tài nguyên).

Phương pháp RED cho service

Với mỗi service hoặc endpoint: Rate (số request mỗi giây), Errors (số request lỗi), Duration (phân bố thời gian xử lý). RED trả lời câu hỏi "service có đang phục vụ tốt không".

Phương pháp USE cho tài nguyên

Do Brendan Gregg đề xuất, áp dụng cho CPU, bộ nhớ, đĩa, mạng, connection pool: Utilization (mức sử dụng), Saturation (lượng việc phải xếp hàng), Errors (lỗi phần cứng, lỗi I/O). USE giúp tìm nguyên nhân khi RED cho thấy có vấn đề.

Chỉ số nghiệp vụ thường bị quên nhưng rất giá trị: số đơn hàng giảm đột ngột về 0 trong giờ cao điểm là tín hiệu sự cố rõ ràng nhất, kể cả khi mọi chỉ số kỹ thuật đều "xanh".

Đặt SLO trước khi đặt cảnh báo

SLI (Service Level Indicator) là chỉ số đo chất lượng, ví dụ tỷ lệ request trả về thành công trong dưới 500 ms. SLO (Service Level Objective) là mục tiêu cho chỉ số đó trong một khoảng thời gian, ví dụ 99,5% trong 30 ngày. Phần còn lại, 0,5%, là ngân sách lỗi (error budget).

Lợi ích của SLO:

• Đội và bên kinh doanh thống nhất "đủ tốt" là thế nào, tránh đòi hỏi 100% không thực tế.
• Cảnh báo dựa trên tốc độ tiêu hao ngân sách lỗi (burn rate) thay vì ngưỡng tùy ý, giảm cảnh báo giả.
• Khi ngân sách lỗi cạn, ưu tiên ổn định trước tính năng mới; khi còn nhiều, có thể mạnh dạn release.

Bắt đầu với một hai SLO cho luồng quan trọng nhất (đăng nhập, đặt hàng, thanh toán), không cần đặt cho mọi thứ.

Dựng bộ công cụ

Bộ mã nguồn mở phổ biến:

• Prometheus: thu thập metrics theo mô hình kéo (scrape), lưu dạng chuỗi thời gian, truy vấn bằng PromQL. Có exporter cho hầu hết hệ thống (node, PostgreSQL, Redis, Nginx).
• Grafana: dashboard, hỗ trợ nhiều nguồn dữ liệu, có hệ thống cảnh báo.
• Alertmanager: gom nhóm, khử trùng lặp, định tuyến cảnh báo tới email, Slack, Telegram, hệ thống trực.
• Lưu trữ dài hạn: Thanos, Mimir hoặc VictoriaMetrics khi cần giữ metrics lâu và gộp nhiều cụm.
• OpenTelemetry: chuẩn mở để ứng dụng phát metrics, traces, logs, tránh khóa vào một nhà cung cấp.

Dịch vụ thương mại hoặc dịch vụ của nhà cung cấp cloud giảm công vận hành, đổi lại chi phí tính theo số host, số chuỗi metrics hoặc dung lượng dữ liệu.

Khi gắn nhãn (label) cho metrics, tránh nhãn có số lượng giá trị lớn như mã người dùng hay URL đầy đủ có tham số; chúng làm bùng nổ số chuỗi thời gian và khiến Prometheus tốn bộ nhớ.

Thiết kế cảnh báo ít nhiễu

Cảnh báo quá nhiều khiến người trực mệt mỏi và bỏ qua cả cảnh báo thật. Nguyên tắc:

1. Cảnh báo theo triệu chứng, không theo nguyên nhân: báo khi tỷ lệ lỗi hoặc độ trễ người dùng thấy vượt mức, không báo chỉ vì CPU 80% nếu người dùng vẫn ổn.
2. Mỗi cảnh báo phải hành động được: nếu nhận cảnh báo mà không biết làm gì, hoặc chẳng cần làm gì, hãy xóa hoặc hạ cấp nó.
3. Phân hai mức: cần xử lý ngay (gọi người trực cả đêm) và có thể xử lý trong giờ làm (tạo ticket).
4. Kèm runbook: mỗi cảnh báo có đường dẫn tới tài liệu: ý nghĩa, dashboard liên quan, bước kiểm tra đầu tiên.
5. Tránh ngưỡng tức thời: yêu cầu điều kiện kéo dài vài phút để loại dao động ngắn.

Một số cảnh báo dựa trên nguyên nhân vẫn đáng có vì báo trước sự cố: đĩa sắp đầy trong vài giờ tới, chứng chỉ TLS sắp hết hạn, bản sao lưu đêm qua thất bại.

Giám sát bảo mật song song với hiệu năng

Hệ thống monitoring cũng nên theo dõi tín hiệu bất thường về bảo mật: số đăng nhập thất bại tăng vọt, lưu lượng ra ngoài lớn bất thường, tiến trình lạ trên máy chủ. Các tín hiệu này nên được chuyển tới người phụ trách bảo mật; bài đảm bảo an toàn dữ liệu cho doanh nghiệp nói rõ hơn về vai trò của giám sát trong phòng thủ.

Quy trình khi sự cố xảy ra

• Lịch trực rõ ràng, có người dự phòng, có cách liên lạc khi cảnh báo không được xác nhận.
• Một kênh trao đổi riêng cho từng sự cố, một người điều phối, cập nhật trạng thái cho bên kinh doanh định kỳ.
• Ưu tiên khôi phục dịch vụ (rollback, chuyển tải) trước khi tìm nguyên nhân gốc.
• Sau sự cố, viết báo cáo không đổ lỗi (blameless postmortem): diễn biến, tác động, nguyên nhân, việc cần làm để không lặp lại; theo dõi các việc này tới khi xong.

Lộ trình cho đội mới bắt đầu

1. Tuần đầu: kiểm tra uptime từ bên ngoài cho trang chủ và API chính; metrics hạ tầng cơ bản.
2. Tiếp theo: thêm metrics RED cho mọi service, dashboard tổng quan một màn hình.
3. Sau đó: định nghĩa SLO cho hai luồng quan trọng, chuyển cảnh báo sang dựa trên SLO.
4. Dần dần: thêm tracing, chỉ số nghiệp vụ, runbook cho từng cảnh báo và diễn tập sự cố định kỳ.

Dữ liệu monitoring còn là đầu vào tốt cho việc tối ưu: các endpoint có p99 cao nhất chính là ứng viên đầu tiên trong danh sách tối ưu hiệu năng ứng dụng web.