Bạn sẽ thiết kế monitoring cho một ứng dụng từ con số 0 như thế nào?

Question

Accepted Answer

Hãy bắt đầu **top-down từ thứ user cảm nhận**, không phải bottom-up từ hạ tầng. Một cụm host ổn định nhất cũng vô nghĩa nếu request đang fail, nên hãy khởi đầu bằng các **SLI** hướng người dùng — **latency**, **error rate**, **availability** — rồi mới thêm bốn golden signal, và cuối cùng mới đến infra metrics.

## Phân lớp, từ user hướng vào trong

```text
1. SLI HƯỚNG USER    → thứ user trải nghiệm (latency, errors, availability)
2. GOLDEN SIGNALS    → latency, traffic, errors, saturation theo từng service
3. INFRA METRICS     → CPU, memory, disk, network (nguyên nhân, không phải triệu chứng)
```

Nếu bạn chỉ theo dõi CPU và disk (bottom-up), bảng có thể toàn màu xanh trong khi user nhận 500. Theo dõi SLI trước (top-down) nghĩa là bạn alert trên **triệu chứng mà user thực sự cảm nhận**, rồi mới drill down vào golden signal và infra để tìm nguyên nhân.

## Pipeline: instrument → collect → dashboard → alert

```text
INSTRUMENT  app phát ra metrics/logs/traces (vd. histogram request_duration_seconds)
   ↓
COLLECT     một TSDB scrape/ingest chúng (Prometheus, Datadog agent)
   ↓
DASHBOARD   trực quan hóa SLI + golden signals (Grafana) cho con người đọc
   ↓
ALERT       kích hoạt khi vi phạm SLO / burn rate, định tuyến tới on-call
```

## Một điểm khởi đầu cụ thể

```promql
# SLI availability: tỷ lệ request thành công
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# SLI latency: latency request ở p99
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

Định nghĩa một **SLO** cho mỗi SLI (vd. 99.9% availability, p99 < 300ms), đưa lên dashboard, và alert khi SLO có nguy cơ bị phá vỡ — không phải mỗi lần có một gợn nhỏ.

## Tại sao điều này quan trọng

Monitoring xây bottom-up cho bạn biết disk đầy 80% nhưng không cho biết khách không thanh toán được. Bắt đầu từ các SLI hướng người dùng buộc mọi dashboard và alert gắn ngược về tác động thực tới user, giữ nhiễu ở mức thấp, và cho một lối drill-down rõ ràng (triệu chứng → golden signal → nguyên nhân infra) khi có sự cố.