Login

Monitoring, logging và tracing: ba trụ cột của observability

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Hệ thống chạy production sẽ có lúc gặp sự cố. Câu hỏi là bạn phát hiện nó trước hay người dùng phát hiện trước, và bạn mất bao lâu để tìm ra nguyên nhân. Observability (khả năng quan sát) cung cấp ba loại dữ liệu bổ trợ nhau giúp trả lời các câu hỏi đó.

Monitoring khác observability thế nào?

Monitoring (giám sát) trả lời câu hỏi bạn đã biết trước: CPU bao nhiêu phần trăm, trang web còn sống không. Observability là khả năng đặt thêm những câu hỏi mới về hành vi hệ thống, kể cả khi chưa từng nghĩ tới trước đó, nhờ có đủ dữ liệu bên trong. Có thể hiểu monitoring là cái bảng đồng hồ, observability là khả năng mở nắp ca-pô để tìm hiểu.

Trụ cột 1: Metrics (số đo)

Metrics là các con số theo thời gian: số yêu cầu mỗi giây, thời gian phản hồi, mức dùng RAM, số lỗi. Chúng nhỏ gọn, rẻ để lưu và rất hợp để vẽ biểu đồ và đặt cảnh báo.

  • Trả lời tốt: có vấn đề không? mức độ ra sao? xu hướng thế nào?
  • Hạn chế: cho biết cái gì hỏng nhưng ít khi cho biết tại sao.

Trụ cột 2: Logs (nhật ký)

Log là các bản ghi sự kiện có dấu thời gian: yêu cầu nào đến, lỗi nào xảy ra, người dùng nào thực hiện hành động. Log chi tiết nhất, nên là nơi bạn tìm nguyên nhân cụ thể.

  • Trả lời tốt: chuyện gì đã xảy ra ở thời điểm đó?
  • Hạn chế: dung lượng lớn, khó tìm nếu không có cấu trúc.

Nên ghi log dạng có cấu trúc (JSON) để dễ lọc và tìm kiếm:

{"time":"2025-01-10T09:15:02Z","level":"error","msg":"thanh toan that bai","order_id":1234,"ma_loi":"TIMEOUT"}

Trụ cột 3: Traces (dấu vết)

Khi một yêu cầu đi qua nhiều dịch vụ (cổng API, dịch vụ đơn hàng, dịch vụ thanh toán, database), trace theo dõi hành trình đó từ đầu đến cuối và chỉ ra mỗi chặng mất bao lâu. Nhờ vậy bạn thấy ngay đoạn nào là điểm nghẽn.

  • Trả lời tốt: yêu cầu chậm ở đâu trong chuỗi dịch vụ?
  • Hạn chế: cần gắn công cụ vào mã nguồn; chủ yếu hữu ích khi hệ thống có nhiều thành phần.

Ba loại dữ liệu phối hợp ra sao?

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

  1. Cảnh báo từ metrics: tỉ lệ lỗi tăng cao lúc 14 giờ.
  2. Trace cho thấy các yêu cầu chậm đều dừng lâu ở dịch vụ thanh toán.
  3. Log của dịch vụ đó cho biết lỗi hết thời gian chờ khi gọi bên thứ ba.

Mỗi loại dữ liệu thu hẹp phạm vi tìm kiếm cho bước sau. Thiếu một loại là bạn phải đoán.

Bốn tín hiệu vàng nên theo dõi

Khi mới bắt đầu, hãy theo dõi bốn thứ cho mỗi dịch vụ:

  • Độ trễ: yêu cầu mất bao lâu để xử lý.
  • Lưu lượng: số yêu cầu mỗi giây.
  • Lỗi: tỉ lệ yêu cầu thất bại.
  • Độ bão hòa: tài nguyên đang được dùng đến mức nào (CPU, RAM, ổ đĩa).

Bắt đầu từ đâu với dự án nhỏ?

  1. Có một kiểm tra từ bên ngoài xem trang còn trả lời không và báo qua email hoặc tin nhắn.
  2. Ghi log có cấu trúc, lưu lại có xoay vòng để không đầy ổ đĩa.
  3. Theo dõi CPU, RAM, ổ đĩa của máy chủ.
  4. Thêm cảnh báo cho vài điều thật sự quan trọng.
  5. Khi hệ thống lớn lên mới đầu tư vào trace phân tán.

Sai lầm thường gặp

  • Thu thập mọi thứ nhưng không bao giờ xem.
  • Cảnh báo quá nhiều đến mức mọi người bỏ qua tất cả.
  • Ghi mật khẩu, token hay dữ liệu cá nhân vào log.
  • Chỉ theo dõi máy chủ mà không theo dõi trải nghiệm của người dùng.

Kết luận

Metrics cho bạn biết có vấn đề, trace chỉ ra vấn đề nằm đâu, log giải thích vì sao. Không cần mua giải pháp đắt tiền ngay; hãy bắt đầu với những gì đơn giản và mở rộng khi nhu cầu thật sự xuất hiện.

Nếu bạn muốn xây dựng hệ thống giám sát hoàn chỉnh cho dự án của mình, các khóa học trên codebem.com là điểm xuất phát tốt.

author_photo
Nguyễn Đình Cường

0 comment