Observability thực chiến: log, metric, trace và SLO cho production

Observability khác monitoring ở điểm nào?#

Monitoring thường bắt đầu từ dashboard và alert: CPU cao, request lỗi, database chậm. Observability đi xa hơn: nó giúp team đặt câu hỏi mới về hệ thống mà không cần deploy thêm code chỉ để debug. Khi production có sự cố, bạn cần biết request nào lỗi, user nào bị ảnh hưởng, dependency nào chậm, và thay đổi nào vừa được release.

Ba tín hiệu nền tảng gồm log, metric và trace. Log ghi sự kiện chi tiết; metric đo xu hướng theo thời gian; trace nối các bước trong một request đi qua nhiều service. Nếu thiếu một trong ba, việc điều tra thường biến thành đoán mò.

Log phải có cấu trúc và correlation id#

Log dạng text tự do rất khó truy vấn khi traffic tăng. Với API production, hãy ưu tiên structured log dạng JSON và luôn gắn request id hoặc correlation id. Id này nên đi từ reverse proxy vào application, database query, background job và log lỗi.

{
  "level": "error",
  "request_id": "req_7f2a",
  "route": "POST /api/orders",
  "user_id": "u_123",
  "duration_ms": 842,
  "error_code": "payment_timeout"
}

Không log password, access token, refresh token, secret, số thẻ, hoặc dữ liệu cá nhân không cần thiết. Log hữu ích phải đủ ngữ cảnh để debug nhưng không biến thành kho dữ liệu nhạy cảm.

Metric nên gắn với trải nghiệm người dùng#

Metric hạ tầng như CPU và memory vẫn cần, nhưng alert quan trọng nên bám vào triệu chứng người dùng: tỷ lệ lỗi tăng, latency p95 vượt ngưỡng, checkout thất bại, job quan trọng bị backlog, hoặc API trả 5xx nhiều hơn bình thường. Với web/API, bốn nhóm metric thực dụng là traffic, error, latency và saturation.

• Traffic: request rate, active users, queue throughput.
• Error: 4xx theo loại, 5xx, exception rate, failed job.
• Latency: p50, p95, p99 theo route hoặc dependency.
• Saturation: CPU, memory, DB connections, queue depth, disk.

Trace cho biết request chậm ở đâu#

Trace đặc biệt hữu ích khi một request đi qua frontend, API gateway, backend, cache, database và service bên thứ ba. Thay vì chỉ biết endpoint mất 2 giây, trace cho bạn thấy 1.4 giây nằm ở query database, 400ms ở payment API và 150ms ở render.

Không phải mọi request đều cần trace đầy đủ. Có thể sampling theo tỷ lệ, tăng sampling khi lỗi, hoặc trace toàn bộ route quan trọng trong giai đoạn điều tra. Điều quan trọng là trace id phải xuất hiện trong log để bạn chuyển qua lại giữa hai nguồn dữ liệu.

SLO giúp alert có kỷ luật#

Nếu alert chỉ dựa trên cảm tính, team sẽ sớm bị mệt vì cảnh báo nhiễu. SLO định nghĩa mức dịch vụ mong muốn từ góc nhìn user, ví dụ 99.9% request đọc bài viết trả về dưới 800ms trong 30 ngày, hoặc 99.5% form liên hệ xử lý thành công.

Khi có SLO, bạn có error budget. Nếu budget bị tiêu quá nhanh, team ưu tiên độ ổn định thay vì tiếp tục ship rủi ro. Alert tốt nên báo khi user bị ảnh hưởng hoặc error budget cháy nhanh, không phải khi một metric nhỏ nhảy lên trong vài giây.

Checklist observability cho web app#

• Log có cấu trúc, request id, route, status code và duration.
• Public API có metric request rate, error rate và latency p95/p99.
• Background job có metric queue depth, retry count và dead-letter count.
• Database có slow query log, connection count và backup status.
• Trace id liên kết được log, metric exemplar và trace.
• Alert bám vào SLO hoặc triệu chứng người dùng bị ảnh hưởng.
• Dashboard tách rõ overview, dependency, release và business flow chính.

Nguồn tham khảo chính#

• OpenTelemetry Docs: Signals
• Google SRE Book: Service Level Objectives
• Prometheus Docs: Alerting