Lesson 9.3: Metrics & Alerting

Thời lượng: 20 phút
Level: Advanced
Yêu cầu: Đã hiểu về Logging và Tracing.

Mục tiêu bài học

Sau bài học này, bạn sẽ:

• Hiểu 4 chỉ số vàng (Golden Signals) để giám sát API.
• Phân biệt được các loại Metrics: Counter, Gauge và Histogram.
• Xây dựng được chiến lược cảnh báo (Alerting) hiệu quả, tránh gây nhiễu cho team.

Nội dung chính

1. Bốn chỉ số vàng (Golden Signals)

Đây là 4 con số quan trọng nhất bạn cần nhìn vào Dashboard để biết hệ thống có đang "khỏe" hay không:

1. Latency (Độ trễ): Thời gian để thực hiện một yêu cầu. (Đơn vị: ms).
2. Traffic (Lưu lượng): Số lượng yêu cầu đang gửi đến hệ thống. (Đơn vị: requests/sec).
3. Errors (Lỗi): Tỷ lệ lỗi trên tổng số yêu cầu. (Đơn vị: %).
4. Saturation (Độ bão hòa): Mức độ sử dụng tài nguyên (CPU, RAM, Disk).

2. Các loại dữ liệu Metrics

• Counter (Bộ đếm): Con số chỉ tăng lên (VD: Tổng số request, Tổng số tiền giao dịch).
• Gauge (Thước đo): Con số có thể tăng hoặc giảm (VD: Tỉ lệ CPU hiện tại, số người dùng đang online).
• Histogram/Summary: Phân phối các giá trị (VD: 95% người dùng có độ trễ dưới 200ms - p95).

3. Thiết lập Cảnh báo (Alerting)

Đừng gán cảnh báo cho mọi thứ. Bạn sẽ sớm bị "Lờn thuốc" (Alert Fatigue) nếu điện thoại rung lên 100 lần mỗi ngày vì những lỗi nhỏ.

Tiêu chí cảnh báo tốt:

• Actionable: Cảnh báo phải kèm theo hành động cụ thể. Nếu nhận cảnh báo mà không làm gì được thì đừng cảnh báo.
• Urgency: Phân cấp cảnh báo (P1: Chết hệ thống -> Gọi điện; P2: Chậm dần -> Nhắn tin Slack).
• SLO-based: Dựa trên cam kết chất lượng dịch vụ (Service Level Objective). (VD: Nếu tỷ lệ lỗi vượt quá 0.1% trong vòng 5 phút -> Báo động).

Nguyên tắc then chốt

"Monitor the user success, not just the server metrics."

Đôi khi CPU server rất thấp (mọi thứ trông có vẻ ổn), nhưng doanh thu lại về 0 vì nút "Thanh toán" bị hỏng logic. Hãy luôn giám sát các chỉ số phản ánh trực tiếp trải nghiệm người dùng.

Thực hành

Bài tập 1: Thiết lập Dashboard cho một API Gateway

Yêu cầu:

• Bạn được giao thiết kế một màn hình Grafana cho hệ thống. Hãy chọn 3 biểu đồ (Chart) quan trọng nhất bạn muốn để ở vị trí to nhất.
• Giải thích tại sao chọn 3 chỉ số đó.

Tình huống thực tế

Scenario 1: Sập hệ thống lúc 2 giờ sáng

Bối cảnh: Disk của DB server bị đầy. Ổ cứng 100% -> DB không thể ghi thêm dữ liệu -> Website báo lỗi 500 toàn bộ.

Giải quyết:

1. Cảnh báo sớm: Thiết lập Alert: "Gửi cảnh báo qua Slack khi Disk Usage > 80%". "Gọi điện cho trực ca khi Disk Usage > 95%".
2. Auto-scaling: Nếu là môi trường Cloud, ta có thể thiết lập tự động mở rộng ổ cứng khi bộ nhớ sắp hết. Nhờ có Metrics và Alerting, bạn có thể xử lý xong vấn đề ở mức 80% (lúc 8h tối) thay vì để nó bùng phát thành thảm họa vào lúc 2h sáng.

Câu hỏi phỏng vấn

Senior Level

1. Q: "Alert Fatigue" là gì và làm thế nào để tránh nó? A: Alert Fatigue là hiện tượng team bị "chai lỳ" với các thông báo cảnh báo vì nó quá nhiều và không quan trọng. Để tránh:
   • Chỉ báo động trên các chỉ số ảnh hưởng trực tiếp đến End-user.
   • Sử dụng cơ chế "Deduplication" (nhóm các lỗi giống nhau vào 1 thông báo).
   • Thiết lập ngưỡng (Threshold) và thời gian chờ (Duration) thông minh.

Tóm tắt

Những điều cần nhớ

• Theo dõi 4 chỉ số vàng (Latency, Traffic, Errors, Saturation).
• Dùng P95, P99 thay vì tính Trung bình (Average) cho độ trễ.
• Cảnh báo phải mang tính hành động (Actionable).

Lời kết hành trình

🎉 Chúc mừng! Bạn đã hoàn thành toàn bộ khóa học Backend Design System Mastery.

Hành trình của chúng ta đã đi qua:

1. Khởi tạo: Định nghĩa chuẩn mực và MVP.
2. Hợp đồng: Thiết kế API chuyên nghiệp.
3. Cấu trúc: REST Patterns và Nesting.
4. Bảo mật: JWT và Phân quyền.
5. Hiệu năng: Caching, Rate Limiting, Reliability.
6. Công cụ: Documentation và Quan sát (Observability).

Bạn hiện đã sở hữu tư duy và bộ công nghệ của một Backend Architect thực thụ. Hãy áp dụng những kiến thức này để xây dựng những hệ thống vĩ đại!

Quay lại Roadmap chính →