Hai giờ sáng, điện thoại reo: "Khách hàng báo thanh toán chậm". Bạn mở dashboard, CPU bình thường, bộ nhớ ổn định. Bạn đọc log và chìm trong hàng nghìn dòng không biết dòng nào liên quan. Hệ thống có năm dịch vụ, request đi qua tất cả, nhưng không rõ chậm ở đâu. Đây chính là lúc bạn cần observability (khả năng quan sát): năng lực hiểu được chuyện gì đang xảy ra bên trong hệ thống chỉ bằng cách nhìn vào dữ liệu nó phát ra, kể cả với những sự cố bạn chưa từng lường trước.

Monitoring và observability khác nhau thế nào?

Monitoring truyền thống trả lời những câu hỏi biết trước: CPU có vượt 80% không, dịch vụ có trả lỗi 500 không. Observability rộng hơn: nó cho phép bạn đặt ra những câu hỏi mới khi sự cố xảy ra, ví dụ "vì sao chỉ người dùng ở khu vực X dùng phiên bản app Y bị chậm?". Monitoring là một phần của observability, không phải thứ bị thay thế.

Observability thường được xây dựng trên ba loại tín hiệu chính: logs, metrics và traces.

Logs: nhật ký sự kiện

Log là bản ghi về một sự kiện cụ thể tại một thời điểm: một request đến, một lỗi xảy ra, một đơn hàng được tạo. Log giàu ngữ cảnh nhất trong ba loại tín hiệu.

Để log thực sự hữu ích:

  • Dùng log có cấu trúc (thường là JSON) thay vì chuỗi văn bản tự do, để dễ lọc và truy vấn.
  • Dùng cấp độ log hợp lý: debug, info, warn, error.
  • Gắn mã định danh như trace_id, user_id, order_id để liên kết các sự kiện.
  • Không ghi dữ liệu nhạy cảm: mật khẩu, token, số thẻ.
{"level":"error","time":"2026-10-16T02:03:11Z","service":"payment",
 "trace_id":"4bf92f3577b34da6","order_id":"A1029",
 "msg":"payment gateway timeout","duration_ms":5003}

Nhược điểm của log là khối lượng lớn, chi phí lưu trữ cao, và khó nhìn ra xu hướng tổng thể.

Metrics: con số theo thời gian

Metric là giá trị số được đo định kỳ và tổng hợp: số request mỗi giây, tỷ lệ lỗi, độ trễ phân vị 95, dung lượng hàng đợi. Metric gọn nhẹ, rẻ để lưu trữ lâu dài và rất phù hợp để vẽ dashboard, đặt cảnh báo.

Các loại metric cơ bản:

  • Counter: chỉ tăng, ví dụ tổng số request.
  • Gauge: tăng giảm tự do, ví dụ số kết nối đang mở.
  • Histogram: phân phối giá trị, dùng để tính độ trễ theo phân vị.

Google SRE đề xuất bốn "tín hiệu vàng" nên theo dõi cho mọi dịch vụ: latency (độ trễ), traffic (lưu lượng), errors (lỗi) và saturation (mức độ bão hoà tài nguyên). Đây là điểm khởi đầu tuyệt vời nếu bạn chưa biết nên đo gì.

Một lưu ý quan trọng: tránh gắn nhãn có quá nhiều giá trị khác nhau (như user_id) vào metric. Điều này gây bùng nổ số chuỗi thời gian (high cardinality), làm hệ thống lưu metric chậm và tốn kém.

Traces: hành trình của một request

Trong hệ thống phân tán, một request của người dùng có thể đi qua API gateway, dịch vụ đơn hàng, dịch vụ thanh toán, database và hàng đợi. Distributed tracing ghi lại toàn bộ hành trình đó.

  • Một trace đại diện cho toàn bộ hành trình của một request.
  • Trace gồm nhiều span, mỗi span là một đơn vị công việc (một lời gọi HTTP, một truy vấn SQL) với thời điểm bắt đầu, thời lượng và thuộc tính.
  • Context propagation: mã trace được truyền qua các dịch vụ, thường qua header HTTP theo chuẩn W3C Trace Context, để các span nối thành một cây hoàn chỉnh.

Nhìn vào trace, bạn thấy ngay span nào chiếm nhiều thời gian nhất, chẳng hạn cổng thanh toán mất năm giây trong khi các bước khác chỉ vài mili giây.

Ba tín hiệu bổ trợ cho nhau

Một quy trình điều tra sự cố điển hình:

  1. Metrics phát hiện vấn đề: cảnh báo tỷ lệ lỗi của dịch vụ thanh toán tăng vọt.
  2. Traces khoanh vùng: các trace lỗi đều chậm ở bước gọi cổng thanh toán bên ngoài.
  3. Logs giải thích chi tiết: log tại span đó cho thấy lỗi timeout kèm mã phản hồi cụ thể.

Sức mạnh thực sự đến từ việc liên kết ba tín hiệu bằng các định danh chung như trace_id, để bạn nhảy từ biểu đồ sang trace rồi sang log chỉ bằng vài cú nhấp.

OpenTelemetry: tiêu chuẩn mở

OpenTelemetry (OTel) là dự án mã nguồn mở thuộc CNCF, cung cấp API, SDK và công cụ thống nhất để thu thập logs, metrics và traces. Lợi ích lớn nhất là không phụ thuộc nhà cung cấp: bạn đo đạc ứng dụng một lần, sau đó có thể gửi dữ liệu tới Prometheus, Jaeger, Grafana hay các nền tảng thương mại mà không phải sửa code.

Các thành phần chính:

  • SDK và thư viện instrumentation: nhiều ngôn ngữ có instrumentation tự động cho framework web, HTTP client, driver database.
  • OpenTelemetry Collector: trung gian nhận, xử lý (lọc, lấy mẫu, gắn thêm thuộc tính) và chuyển tiếp dữ liệu tới backend.
  • OTLP: giao thức truyền dữ liệu chuẩn của dự án.

Lộ trình xây dựng thực tế

  1. Chuẩn hoá log có cấu trúc và tập trung log về một nơi.
  2. Thu thập bốn tín hiệu vàng cho từng dịch vụ, đặt cảnh báo dựa trên triệu chứng người dùng cảm nhận được.
  3. Bật tracing với OpenTelemetry, bắt đầu từ instrumentation tự động.
  4. Liên kết log với trace bằng trace_id.
  5. Định nghĩa SLO (mục tiêu mức dịch vụ) và cảnh báo theo SLO để giảm cảnh báo nhiễu.

Kết luận

Observability không phải một công cụ mua về là có, mà là năng lực được xây dựng dần qua cách bạn viết code và vận hành hệ thống. Logs cho ngữ cảnh chi tiết, metrics cho cái nhìn tổng thể và cảnh báo, traces cho bức tranh hành trình request. Khi ba tín hiệu được liên kết và chuẩn hoá bằng OpenTelemetry, những cuộc gọi lúc hai giờ sáng sẽ ngắn hơn rất nhiều.

Nguồn tham khảo