App production của bạn đang chậm. User phàn nàn. Sếp nhắn Slack.
Bạn SSH vào server và… nhìn chằm chằm vào màn hình.
Không có observability, debug production giống như bác sĩ chẩn đoán bệnh nhân mà không được nhìn, sờ, hay nói chuyện với họ. Bài viết này trao cho bạn bộ dụng cụ của Bác sĩ.
Phần 1: Nền tảng (Mô hình tư duy)
Bộ dụng cụ Bác sĩ
Bác sĩ có ba loại dụng cụ cho các câu hỏi khác nhau:
- Ống nghe (Logs): “Để tôi NGHE bệnh nhân đang nói gì từng giây một.” Sự kiện thô. Có timestamp. Chi tiết. Ồn ào.
- Bảng theo dõi sinh hiệu (Metrics): “Để tôi KIỂM TRA các con số quan trọng: nhịp tim, huyết áp, nhiệt độ.” Đã tổng hợp. Là số. Tốt cho dashboard.
- X-Quang (Tracing): “Để tôi NHÌN THẤY bên trong và theo dõi đúng vấn đề này qua từng cơ quan.” Luồng request đầu cuối xuyên suốt các service.
| Trụ cột | Câu hỏi trả lời | Đơn vị | Công cụ |
|---|---|---|---|
| Logs | “Chính xác chuyện gì đã xảy ra?” | Text events | Datadog, Loki, ELK Stack |
| Metrics | “Hệ thống đang như thế nào nói chung?” | Số liệu theo thời gian | Prometheus, Grafana, Datadog |
| Tracing | “Request này bị chậm ở đâu?” | Spans + Traces | Jaeger, Zipkin, OpenTelemetry |
Phần 2: Điều tra (Đi sâu từng Trụ cột)
1. Logs — “Nhật ký của Bệnh nhân”
Log là bản ghi có timestamp về những gì đã xảy ra. Kỷ luật quan trọng nhất: structured logging (log có cấu trúc).
| |
Log Levels (Dùng đúng!):
DEBUG: Chi tiết tỉ mỉ cho dev. Tắt ở production.INFO: Hoạt động bình thường. “User 42 đăng nhập.”WARNING: Có thể sắp có chuyện. “Ổ đĩa đầy 80%.”ERROR: Thứ gì đó thất bại. “Thanh toán thất bại cho đơn 999.”CRITICAL: App đang hấp hối. Người trực on-call thức dậy.
2. Metrics — “Bảng Sinh hiệu”
Metrics cho bạn biết xu hướng thay đổi theo thời gian. Bốn Tín hiệu Vàng (Google SRE):
- Latency: Request mất bao lâu? (p50, p95, p99)
- Traffic: Bao nhiêu request mỗi giây?
- Errors: Bao nhiêu % request thất bại?
- Saturation: Hệ thống đầy bao nhiêu? (CPU %, RAM %, độ sâu Queue)
| |
3. Tracing — “Phim X-Quang”
Trong hệ thống microservices, một request user có thể đi qua 7 service. Nếu mất 2 giây, 2 giây đó ở đâu?
Tracing trả lời bằng Biểu đồ Thác nước (Waterfall):
| |
OpenTelemetry là chuẩn mở. Viết một lần, gửi đến backend nào cũng được (Jaeger, Datadog,…):
| |
Phần 3: Chẩn đoán (Dùng Công cụ Nào?)
| Vấn đề | Nhìn vào đâu trước? | Tại sao |
|---|---|---|
| “Lỗi 500 cho user 42” | Logs | Tìm thông báo lỗi và stack trace chính xác. |
| “API chậm từ 3 giờ chiều” | Metrics | Tìm đỉnh P95 latency trên dashboard. |
| “Request này mất 2s” | Tracing | Xem Waterfall và tìm service nào chậm. |
| “Server bị sập” | Metrics | Alert CPU/Memory kích hoạt trước khi crash. |
Phần 4: Giải pháp (Bộ Alerting)
Bạn không thể ngồi nhìn dashboard 24/7. Bạn cần alerts.
Alert tốt: “P99 latency vượt 2 giây trong 5 phút.” (Cụ thể, có thể hành động). Alert tệ: “CPU trên 50%.” (Mơ hồ, báo liên tục, gây alert fatigue).
| |
Mô hình tư duy chốt hạ
| |
Bạn cần cả ba. Log không có Metrics là bay mù. Metrics không có Tracing là biết mình bệnh nhưng không biết tại sao.
