18. Logging và phân tích log Nginx

1. Vì sao log là “đôi mắt” của Web Server?

Trong vận hành thực tế, rất nhiều câu hỏi chỉ có thể trả lời bằng log:

• Website chậm từ khi nào?

• Người dùng truy cập gì trước khi lỗi xảy ra?

• Lỗi do Nginx, PHP hay ứng dụng?

• Có bị scan, tấn công hay không?

Nếu không có log, hoặc log không được tổ chức tốt:

Vận hành hệ thống sẽ dựa vào phỏng đoán thay vì dữ liệu.

Vì vậy, logging không phải là phần phụ, mà là thành phần bắt buộc của hệ thống production.

2. Các loại log trong Nginx

Nginx có hai loại log chính:

2.1. Access log

• Ghi lại mọi request hợp lệ

• Cho biết:

  • Ai truy cập

  • Truy cập lúc nào

  • Truy cập URL nào

  • HTTP status

  • User-Agent

Mục đích:

• Phân tích lưu lượng

• Truy vết hành vi bất thường

• Đánh giá hiệu năng

2.2. Error log

• Ghi lại lỗi trong quá trình xử lý

• Bao gồm:

  • Lỗi cấu hình

  • Lỗi kết nối backend

  • Lỗi file, permission

  • Warning và critical error

Mục đích:

• Debug sự cố

• Phát hiện lỗi sớm

• Xác định nguyên nhân gốc

3. Vị trí log mặc định của Nginx

Trên Ubuntu, log mặc định nằm tại:

Bao gồm:

• access.log

• error.log

Trong môi trường production nhiều website, không nên dùng log mặc định chung.

4. Cấu hình log riêng cho từng website (bắt buộc)

4.1. Log riêng giúp ích gì?

• Không lẫn dữ liệu giữa các website

• Debug nhanh

• Dễ phân quyền đọc log

• Phân tích chính xác theo từng domain

4.2. Cấu hình log trong server block

Ví dụ:

Nguyên tắc:

Mỗi website phải có access log và error log riêng.

5. Hiểu nội dung access log

Một dòng access log điển hình:

Giải thích nhanh:

• IP truy cập

• Thời gian

• Request

• HTTP status

• Dung lượng response

• User-Agent

Từ đây có thể:

• Phát hiện request bất thường

• Nhận biết bot, scanner

• Phân tích lỗi 404, 500

6. Sử dụng error log để debug sự cố

6.1. Theo dõi log theo thời gian thực

Khi reload cấu hình hoặc test website, error log sẽ cho biết:

• Lỗi cú pháp

• Lỗi permission

• Lỗi kết nối PHP-FPM

6.2. Mức log (log level)

Mặc định Nginx ghi ở mức:

• error

• warn

• crit

Có thể chỉnh (khi cần):

Trong production:

Không nên bật debug trừ khi xử lý sự cố cụ thể.

7. Các lệnh phân tích log cơ bản (không cần tool phức tạp)

7.1. Xem số lượng request theo IP

Dùng để:

• Phát hiện IP truy cập nhiều bất thường

• Phát hiện scan, bot

7.2. Xem lỗi phổ biến (404, 500)

7.3. Xem request gần nhất trước khi lỗi

8. Log rotation – tránh đầy disk

8.1. Vì sao cần logrotate?

Log không được xoay vòng sẽ:

• Tăng dung lượng liên tục

• Làm đầy disk

• Gây sập dịch vụ

Ubuntu đã có logrotate cho Nginx tại:

8.2. Kiểm tra logrotate hoạt động

• Log cũ sẽ được:

  • Nén

  • Đổi tên

  • Xoay vòng theo chu kỳ

Khuyến nghị:

• Kiểm tra định kỳ

• Đảm bảo log không bị giữ vô hạn

9. Những sai lầm phổ biến khi làm việc với log

• Tắt log để “đỡ tốn disk”

• Dùng chung log cho nhiều website

• Không xem log khi có lỗi

• Không bảo vệ quyền truy cập log

Những sai lầm này khiến:

Khi có sự cố, không còn dữ liệu để phân tích.

10. Checklist logging cho Web Server production

•  Mỗi website có log riêng

•  Access log và error log đầy đủ

•  Biết cách đọc log cơ bản

•  Logrotate hoạt động

•  Không bật debug thường xuyên

11. Bài tiếp theo

Trong Bài 19, chúng ta sẽ chuyển sang mảng bảo mật và domain:

Quản lý domain và DNS cho Web Server

Bài này sẽ giúp:

• Tránh lỗi trỏ domain

• Chuẩn bị cho SSL

• Quản lý nhiều domain hiệu quả