1. Tổng quan: Ba thành phần giải quyết ba vấn đề khác nhau
Khi một Backend chạy trên production, việc code hoạt động đúng trên máy local chưa đủ. Hệ thống cần có khả năng ghi nhận sự kiện, phát hiện sự cố và triển khai phiên bản mới một cách an toàn.
Ba thành phần quan trọng là:
- Logging: Ghi lại những sự kiện đã xảy ra trong ứng dụng.
- Monitoring: Theo dõi tình trạng hệ thống thông qua metrics, health checks và cảnh báo.
- CI/CD: Tự động hóa quá trình kiểm tra, build, phát hành và triển khai phần mềm.
Ba thành phần này bổ trợ nhau nhưng không thay thế nhau. Một hệ thống có log đầy đủ vẫn có thể không phát hiện sự cố kịp thời nếu không có monitoring. Một hệ thống có monitoring tốt vẫn có thể khó tìm nguyên nhân nếu log thiếu thông tin. CI/CD nhanh nhưng không có kiểm soát chất lượng có thể khiến lỗi được đưa lên production nhanh hơn.
2. Logging: Ghi lại điều gì đã xảy ra?
Logging là việc ghi lại các sự kiện trong quá trình ứng dụng hoạt động. Log giúp developer và đội vận hành điều tra lỗi, hiểu luồng xử lý và xác định hành vi bất thường.
Log không nên chỉ là những dòng văn bản tùy ý. Trong production, log cần có cấu trúc nhất quán, mức độ nghiêm trọng và thông tin ngữ cảnh đủ để hỗ trợ điều tra.
Structured Logging
Structured logging là cách ghi log dưới dạng dữ liệu có cấu trúc, thường là JSON, thay vì chỉ tạo một câu văn tự do.
Ví dụ log dạng văn bản:
Failed to create order for user 123
Ví dụ structured log:
{
"level": "error",
"message": "failed to create order",
"request_id": "req-abc123",
"user_id": "123",
"order_id": "ord-456",
"error_code": "DATABASE_TIMEOUT"
}
Các trường trên chỉ là ví dụ. Trong thực tế, chỉ nên ghi user_id hoặc order_id khi cần thiết và được phép theo chính sách dữ liệu của hệ thống.
Structured logging có lợi vì công cụ thu thập log có thể lọc, tìm kiếm và tổng hợp theo từng trường. Ví dụ, đội vận hành có thể tìm tất cả lỗi DATABASE_TIMEOUT trong một khoảng thời gian hoặc theo một phiên bản ứng dụng.
2. Monitoring: Hệ thống có đang khỏe mạnh không?
Monitoring là việc theo dõi các chỉ số và trạng thái của hệ thống theo thời gian để phát hiện bất thường, đánh giá hiệu năng và xác định khi nào cần hành động.
Khác với log ghi lại từng sự kiện, monitoring thường tập trung vào các số liệu có thể tổng hợp và theo dõi xu hướng.
Ví dụ:
- Tỷ lệ HTTP
5xxtăng từ 0,1% lên 8%. - Thời gian phản hồi p95 tăng từ 200 ms lên 2 giây.
- Database connection pool gần hết kết nối.
- Queue có ngày càng nhiều job chưa xử lý.
- CPU hoặc memory sử dụng vượt mức bình thường.
Latency và percentile
Latency là thời gian hệ thống cần để xử lý một request.
Không nên chỉ nhìn latency trung bình vì giá trị trung bình có thể che giấu những request chậm.
Ví dụ, phần lớn request mất 100 ms nhưng một số request mất 5 giây. Trung bình có thể vẫn tương đối thấp dù trải nghiệm của một nhóm người dùng rất tệ.
3. Health Check: Liveness và Readiness
Health check là cơ chế kiểm tra trạng thái của ứng dụng, thường được dùng bởi load balancer, container orchestrator hoặc hệ thống giám sát.
Hai khái niệm cần phân biệt:
Liveness: Ứng dụng còn hoạt động hay đã rơi vào trạng thái không thể phục hồi nếu không khởi động lại?
Readiness: Ứng dụng đã sẵn sàng nhận traffic hay chưa?
Không nên để liveness phụ thuộc quá chặt vào mọi dịch vụ bên ngoài. Nếu database tạm thời mất kết nối và liveness của tất cả instance đều thất bại, hệ thống có thể liên tục restart ứng dụng dù restart không giải quyết được nguyên nhân.
Readiness cũng cần được thiết kế theo mục tiêu của dịch vụ. Không phải mọi dependency tùy chọn đều phải khiến toàn bộ ứng dụng ngừng nhận traffic
4. Observability: Logging, Metrics và Tracing
Monitoring và observability có liên quan nhưng không hoàn toàn đồng nghĩa.
Monitoring giúp theo dõi những vấn đề đã xác định trước thông qua dashboard, metric và alert.
Observability là khả năng suy luận trạng thái bên trong của hệ thống từ dữ liệu mà hệ thống phát ra.
Ba loại telemetry thường được nhắc đến:
- Logs: Sự kiện chi tiết đã xảy ra.
- Metrics: Số liệu tổng hợp theo thời gian.
- Traces: Đường đi của một request qua nhiều service hoặc thành phần.
Khi kết hợp ba loại dữ liệu này, việc xác định nguyên nhân thường dễ hơn so với chỉ dùng một loại.
Trong hệ thống nhiều service, nên sử dụng các định danh như trace_id và span_id để kết nối dữ liệu tương ứng. Cần tránh dùng các giá trị có độ đa dạng quá cao như request ID làm nhãn metric, vì có thể gây cardinality tăng mạnh.
5. Kết luận
Logging, Monitoring và CI/CD là ba nền tảng thiết yếu để vận hành Backend đáng tin cậy.
- Logging trả lời: Điều gì đã xảy ra?
- Monitoring trả lời: Hệ thống hiện có đang hoạt động tốt không?
- CI/CD trả lời: Làm thế nào để thay đổi phần mềm được kiểm tra và phát hành an toàn?
Khi kết hợp tốt, chúng giúp đội phát triển phát hiện lỗi sớm, rút ngắn thời gian điều tra và giảm rủi ro khi triển khai.








Khoá học lập trình game con rắn cho trẻ em




