DevOps & Cloud hay gặpNguyên tắc: đo cái người dùng cảm nhận được, cảnh báo theo triệu chứng chứ không theo nguyên nhân, và mỗi alert phải đáng để đánh thức người trực.
Metrics nên thu
- RED (cho request-driven service): Rate (số request/giây), Errors (tỷ lệ lỗi), Duration (latency, xem p50/p95/p99 chứ không chỉ trung bình).
- USE (cho tài nguyên): Utilization, Saturation, Errors của CPU/memory/disk/network — để tìm nút thắt tài nguyên.
- Metric type: counter cho số đếm tích lũy, gauge cho giá trị hiện thời, histogram cho phân bố latency.
Log tập trung: gom log của mọi instance về một nơi (ELK, Loki, CloudWatch), gắn structured logging (JSON) và trace/correlation id để lần một request qua nhiều service. Kết hợp metrics (thấy có vấn đề) + logs/traces (tìm nguyên nhân).
Alert theo SLO / error budget
- Định nghĩa SLI (ví dụ tỷ lệ request thành công) và SLO (ví dụ 99.9%/30 ngày). Phần được phép lỗi là error budget.
- Cảnh báo khi tốc độ đốt error budget (burn rate) cao, không phải mỗi lần lỗi lẻ. Dùng cảnh báo đa cửa sổ: burn nhanh (vài phút) báo gấp, burn chậm (vài giờ) báo nhẹ. Nhờ đó alert gắn với tác động thực tới người dùng.
Tránh alert fatigue
- Chỉ page khi cần hành động ngay của con người; còn lại đưa vào ticket/dashboard.
- Cảnh báo theo triệu chứng người dùng gặp (error rate, latency), không phải mọi biến động CPU.
- Mỗi alert phải actionable và có runbook; gộp alert trùng, đặt ngưỡng gắn với SLO thay vì con số tùy tiện.
Sai lầm hay gặp: chỉ theo dõi average latency (giấu đuôi p99); alert trên nguyên nhân (CPU 80%) thay vì triệu chứng; quá nhiều alert non-actionable khiến người trực dần bỏ qua cảnh báo và bỏ sót sự cố thật.