Login

Đọc và quản lý log hiệu quả khi hệ thống gặp sự cố

  • author-image

    Nguyễn Đình Cường

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

Khi website báo lỗi 500 lúc nửa đêm, thứ đầu tiên bạn cần là log. Log tốt giúp bạn tìm ra nguyên nhân trong vài phút, log tệ khiến bạn mò mẫm hàng giờ. Bài này nói về cách ghi log có ích và cách đọc nhanh khi có sự cố.

Các mức độ log

Hầu hết thư viện log chia thành các mức, từ chi tiết đến nghiêm trọng:

  • DEBUG: thông tin chi tiết cho lập trình viên, thường tắt ở production.
  • INFO: sự kiện bình thường đáng ghi nhận, như dịch vụ khởi động hay đơn hàng được tạo.
  • WARNING: chuyện bất thường nhưng ứng dụng vẫn chạy được.
  • ERROR: một thao tác thất bại.
  • CRITICAL hoặc FATAL: lỗi nghiêm trọng, ứng dụng có thể không tiếp tục được.

Chọn mức đúng giúp lọc nhanh. Nếu mọi thứ đều là ERROR thì chẳng còn cái nào nổi bật.

Một dòng log tốt chứa những gì?

  1. Thời gian chính xác kèm múi giờ (nên dùng UTC).
  2. Mức độ.
  3. Thông điệp rõ nghĩa, nói chuyện gì xảy ra.
  4. Ngữ cảnh: mã yêu cầu, mã người dùng hoặc đơn hàng, để lần theo.
  5. Chi tiết lỗi: tên lỗi và stack trace với lỗi nghiêm trọng.

So sánh hai dòng: 'Lỗi xảy ra' hoàn toàn vô dụng, còn 'Thanh toán thất bại: order=1234 lý do=hết thời gian chờ cổng thanh toán' cho bạn manh mối ngay. Tuyệt đối không ghi mật khẩu, token, số thẻ hay dữ liệu cá nhân vào log.

Mã yêu cầu để lần theo dấu

Gán mỗi yêu cầu một mã định danh duy nhất (request ID) và đưa vào mọi dòng log của yêu cầu đó. Khi người dùng báo lỗi, bạn chỉ cần mã đó để gom toàn bộ hành trình của họ, kể cả khi log từ nhiều dịch vụ.

Công cụ dòng lệnh để đọc log nhanh

tail -f /var/log/nginx/error.log
grep -i 'error' app.log | tail -50
grep 'order=1234' app.log
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
journalctl -u myapp --since '1 hour ago'

Lệnh awk ở dòng thứ tư lấy cột mã trạng thái trong log truy cập mặc định của Nginx rồi đếm số lần xuất hiện của từng mã, giúp bạn thấy ngay tỉ lệ 404, 500. Nếu định dạng log của bạn khác, số cột có thể khác.

Quy trình đọc log khi có sự cố

  1. Xác định thời điểm bắt đầu lỗi.
  2. Xem log lỗi quanh thời điểm đó, bắt đầu từ lỗi đầu tiên chứ không phải lỗi cuối cùng, vì các lỗi sau thường là hệ quả.
  3. Tìm điểm chung: cùng một đường dẫn, cùng người dùng, cùng phiên bản?
  4. Đối chiếu với các thay đổi gần đây như triển khai hay đổi cấu hình.
  5. Ghi lại phát hiện, để làm báo cáo sau sự cố.

Xoay vòng log để không đầy ổ đĩa

File log lớn dần và có thể làm đầy đĩa, làm sập cả máy chủ. Công cụ logrotate trên Linux lo việc này. Ví dụ cấu hình tại /etc/logrotate.d/myapp:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

Cấu hình này xoay vòng mỗi ngày, giữ 14 bản, nén bản cũ, bỏ qua nếu thiếu file hay file rỗng. copytruncate hữu ích khi ứng dụng giữ file mở liên tục, đổi lại có nguy cơ mất vài dòng log trong lúc sao chép.

Khi hệ thống lớn: gom log tập trung

Khi có nhiều máy chủ, đăng nhập vào từng máy để đọc log là bất khả thi. Bạn nên gom log về một nơi tìm kiếm được, bằng các giải pháp như bộ ELK, Loki hay dịch vụ của nhà cung cấp cloud. Với dự án nhỏ một máy chủ thì chưa cần, nhưng hãy ghi log dạng có cấu trúc từ sớm để sau này chuyển đổi dễ dàng.

Kết luận

Log tốt có mức độ đúng, thông điệp rõ, ngữ cảnh đủ và được xoay vòng cẩn thận. Hãy xem lại log của ứng dụng đang làm: nếu gặp sự cố lúc nửa đêm, bạn có đủ thông tin để xử lý trong năm phút không?

Muốn tìm hiểu thêm về vận hành và gỡ lỗi hệ thống thực tế, hãy ghé các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment