Nhật ký lỗi có cấu trúc giúp đội kỹ thuật tìm lại đúng việc đã xảy ra trên website. Mỗi sự kiện được ghi kèm thời điểm, nơi xảy ra và kết quả. Nhờ đó, người quản trị dễ tìm đúng sự cố thay vì đọc hàng nghìn dòng thông báo rời rạc.
Với chủ doanh nghiệp: nếu khách không gửi được liên hệ hoặc thanh toán, hãy cung cấp trang lỗi, thời điểm và kết quả họ nhìn thấy. Đội kỹ thuật sẽ tìm bản ghi liên quan. Những mã như request_id chỉ cần dùng ở phần kỹ thuật bên dưới.
Khi khách báo lỗi, nhật ký website giúp ích gì?
Ví dụ giả định: sau một lần cập nhật WordPress, khách bấm gửi liên hệ nhưng không thấy xác nhận. Đội kỹ thuật có thể tìm các lần gửi lỗi theo thời điểm và phiên bản, rồi kiểm tra hệ thống tiếp nhận. Không nên kết luận ngay plugin mới là nguyên nhân chỉ vì lỗi xuất hiện sau cập nhật.
| Vấn đề khách gặp | Thông tin nên báo | Người kỹ thuật tìm gì? |
|---|---|---|
| Biểu mẫu không gửi được | Trang lỗi, giờ, kết quả thấy trên màn hình | Sự kiện gửi lỗi và mã yêu cầu |
| Đặt hàng hoặc thanh toán đứng | Trạng thái đơn và thời điểm | Lỗi giao dịch, dịch vụ kết nối và mã đối chiếu |
| Trang lỗi sau cập nhật | Trang bị ảnh hưởng và giờ cập nhật | Phiên bản ứng dụng và các bản ghi tương ứng |
Không gửi mật khẩu, mã truy cập, thông tin thẻ hoặc dữ liệu khách hàng vào phiếu báo lỗi. Chỉ cung cấp thông tin cần thiết cho việc xác minh.
Dành cho kỹ thuật: nhật ký thường và nhật ký có cấu trúc
Log thường là những dòng chữ tự do như “Gửi biểu mẫu thất bại”. Với nhiều lượt truy cập hoặc công việc chạy tự động, đội kỹ thuật khó tìm sự kiện liên quan. Log có cấu trúc tách dữ liệu thành các trường cố định để lọc theo thời gian, chức năng hoặc mã yêu cầu.
| Trường trong log | Ý nghĩa |
|---|---|
| timestamp | Thời điểm sự kiện; phải biết rõ múi giờ |
| severity | Mức độ: DEBUG, INFO, WARN, ERROR hoặc CRITICAL |
| service / environment | Thành phần và nơi chạy: website thật hay môi trường thử |
| event_name | Tên sự kiện ổn định như form_submit_failed |
| request_id / correlation_id | Mã kết nối các bản ghi trong một yêu cầu hoặc quy trình |
| route / job | Trang, API hay công việc chạy tự động |
| release / version | Phiên bản và lần cập nhật phần mềm |
| outcome | Kết quả thành công, thất bại, thử lại hoặc hết thời gian chờ |
Ví dụ bản ghi sự cố để đội kỹ thuật tìm lỗi
Đây là ví dụ minh họa, không phải dữ liệu thật. Mỗi dòng gồm những trường có tên cố định như thời gian, loại sự kiện và kết quả. Người đọc phổ thông không cần hiểu mã JSON để nắm được mục đích.
{"timestamp":"2026-10-25T10:00:00+07:00","severity":"ERROR","service":"wordpress","environment":"production","event_name":"form_submit_failed","request_id":"req_demo_42","route":"/lien-he/","release":"v1.2.0","outcome":"failed"}Kỹ thuật có thể tìm theo request_id, tên sự kiện hoặc phiên bản. Mẫu này không chứa họ tên, email, mật khẩu, token hay nội dung biểu mẫu của khách.
DEBUG dùng để điều tra chi tiết; INFO ghi việc bình thường; WARN cảnh báo; ERROR cho biết có lỗi. Chỉ gọi người trực khi lỗi có ảnh hưởng đáng kể. Nếu dòng nào cũng đánh dấu CRITICAL, cảnh báo sẽ mất tác dụng.
Vì sao cần mã để tìm lại đúng lần xảy ra lỗi?
Request ID là mã của một yêu cầu.
Correlation ID có thể nối nhiều bước như gửi biểu mẫu, gọi API và đưa công việc vào hàng đợi. Trace ID/Span ID là mã theo dõi đường đi theo mô hình OpenTelemetry, không mặc định giống Request ID tự tạo. Đọc Correlation ID và Distributed Tracing để hiểu cách nối các hệ thống.
Release marker là dấu mốc phiên bản ứng dụng. Nếu lỗi tăng sau cập nhật, đội vận hành có thể lọc bản ghi theo phiên bản để điều tra. Mối liên hệ về thời gian chưa đủ chứng minh nguyên nhân. Xem quản lý thay đổi WordPress.
Không ghi mật khẩu hoặc thông tin khách vào nhật ký
Log có thể được gửi tới nhiều nơi và lưu lâu hơn dữ liệu ứng dụng. Không ghi mật khẩu, khóa API, mã truy cập, session token, webhook secret hoặc dữ liệu nhận diện cá nhân (PII) không cần thiết.
Với biểu mẫu và thanh toán, thường chỉ cần mã đối chiếu, loại lỗi và kết quả, không cần toàn bộ nội dung khách gửi.
Việc che hoặc loại dữ liệu bí mật trước khi ghi gọi là redaction. Cần làm sạch dữ liệu đầu vào để tránh chèn dòng log giả, hạn chế quyền truy cập và ấn định thời gian lưu (retention) phù hợp. Xem quản lý khóa bí mật và hướng dẫn OWASP về log an toàn.
Bật nhật ký lỗi WordPress có đủ để tìm sự cố không?
WP_DEBUG bật chế độ gỡ lỗi WordPress. WP_DEBUG_LOG giúp ghi lỗi vào tập tin khi WP_DEBUG được bật; WP_DEBUG_DISPLAY điều khiển việc hiện lỗi cho người truy cập. Chúng không tự thêm tên sự kiện, mã yêu cầu hay phiên bản. Kỹ thuật cần bổ sung cách ghi log phù hợp nếu muốn có cấu trúc.
Trên website đang hoạt động, không nên để khách nhìn thấy lỗi nội bộ. Tập tin wp-content/debug.log có nguy cơ bị lộ nếu không giới hạn truy cập. Hãy kiểm tra nơi lưu, quyền xem và thời gian bật debug. WordPress có hướng dẫn riêng về bảo vệ cấu hình và tập tin log.
Khi có cảnh báo, làm sao tìm được nguyên nhân?
Log giải thích chuyện đã xảy ra; giám sát lỗi ứng dụng nhóm các lỗi tương tự. Trace cho thấy đường đi yêu cầu, còn số đo cho biết mức ảnh hưởng. Đọc thêm Website Observability.
Nếu cần cảnh báo khi tỷ lệ lỗi hoặc thời gian phản hồi tăng, dùng giám sát website làm bước phát hiện. Sau cảnh báo mới mở bản ghi liên quan để điều tra, thay vì gửi thông báo khẩn cho từng dòng log.
Dành cho kỹ thuật: 7 bước ghi nhật ký có cấu trúc
- Chọn sự kiện: ưu tiên biểu mẫu, đơn hàng, API, webhook, công việc theo lịch và cập nhật quan trọng.
- Thống nhất trường: thời gian, mức độ, thành phần, tên sự kiện, mã yêu cầu, phiên bản và kết quả.
- Che dữ liệu: loại mật khẩu, token và thông tin khách không cần thiết trước khi ghi.
- Nơi lưu và hạn giữ: chốt quyền xem, vị trí lưu, dung lượng và thời gian lưu.
- Cách tìm lỗi: chuẩn bị cách lọc theo thời gian, mã và hướng dẫn xử lý (runbook).
- Gắn với cảnh báo: từ lỗi truy được log và trace tương ứng nếu hệ thống hỗ trợ.
- Kiểm tra lại: giảm bản ghi thừa, kiểm tra bí mật và hiệu quả tìm lỗi.
Chủ doanh nghiệp nghiệm thu nhật ký như thế nào?
- Thử một sự kiện an toàn; tìm đúng thời điểm, chức năng, mức độ và kết quả.
- Tìm được các bản ghi liên quan bằng request ID hoặc correlation ID.
- Đối chiếu được phiên bản WordPress hoặc phần mềm đã thay đổi.
- Xác nhận log không chứa mật khẩu, token, thông tin khách không cần thiết.
- Người không có quyền không thể truy cập hoặc tải log.
- Có thời hạn lưu, người phụ trách và cách kiểm tra sau khi lỗi được sửa.
Chủ doanh nghiệp chỉ cần yêu cầu một ví dụ kiểm tra đã che thông tin khách. Đội kỹ thuật phải chỉ ra sự kiện xảy ra lúc nào, việc gì bị lỗi và kết quả sau sửa, thay vì chỉ nói “đã bật log”.
Kết luận
Structured Logging giúp tìm đúng sự kiện, đúng thời điểm và đúng phiên bản khi website gặp lỗi. Đây là một phần của Website Observability. Log cần đủ ngữ cảnh để điều tra, nhưng không nên chứa dữ liệu dư hoặc bí mật.
Nguồn tham khảo: OpenTelemetry Logs; OpenTelemetry Logging Specification; WordPress – Debugging in WordPress.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.