Giới thiệu

Loggin là công cụ giúp ghi lại lịch sử hoạt động của hệ thống nginx, rất hữu dụng cho việc debug sau này.

Tìm hiểu file log

Về mặc định, nginx sẽ lưu log tự động, hãy dùng câu lệnh sau để xem các file log mặc định

ls -lh /var/log/nginx/

kết quả

# -rw-r----- 1 www-data adm     0 Apr 25 07:34 access.log
# -rw-r----- 1 www-data adm     0 Apr 25 07:34 error.log

Đây là 2 file log mặc định của nginx, giờ ta sẽ xoá nội dung của 2 file thông qua các câu lệnh sau

Bước 1 : xoá file

sudo rm /var/log/nginx/access.log /var/log/nginx/error.log

Bước 2 : tạo file mới

sudo touch /var/log/nginx/access.log /var/log/nginx/error.log

Bước 3 : khởi động lại nginx

sudo nginx -s reopen

Giờ ta hãy thử kiểm tra xem hệ thống có ghi log thành công hay chưa bằng các câu lệnh sau:

Bước 1 : Gọi URL bất kỳ

curl -I http://nglearns.test

Bước 2 : Mở file log

sudo cat /var/log/nginx/access.log 

Kết quả

# 192.168.20.20 - - [25/Apr/2021:08:35:59 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.68.0"

Như các bạn đã thấy, ta đã có thể thấy được việc ghi log đã được ghi vào đúng file.

Kiểm soát việc ghi log

Ta có thể kiểm soát việc ghi log vào file nào theo ý muốn. Hãy tham khảo ví dụ sau:

events {
}

http {
  include /etc/nginx/mime.types;
  server {
    listen 80;
    server_name nglearns.test;

    location / {
      return 200 "this will be logged to the default file.\n";
    }

    location = /admin {
      access_log /var/logs/nginx/admin.log;
        
      return 200 "this will be logged in a separate file.\n";
    }
    
    location = /no_logging {
      access_log off;
      
      return 200 "this will not be logged.\n";
    }
  }
}

Tại đây, chúng ta có thể thấy, ta sử dụng access_log trong /admin để yêu cầu nginx viết log vào file admin.log. Còn trong /no_logging, chúng ta yêu cầu nginx ngừng ghi log trên file đã yêu cầu thông qu câu lệnh access_log off

Để kiểm chứng, chúng ta sẽ thực nghiệp như sau:

curl http://nginx-handbook.test/no_logging
# this will not be logged

sudo cat /var/log/nginx/access.log
# empty

curl http://nginx-handbook.test/admin
# this will be logged in a separate file.

sudo cat /var/log/nginx/access.log
# empty

sudo cat /var/log/nginx/admin.log 
# 192.168.20.20 - - [25/Apr/2021:11:13:53 +0000] "GET /admin HTTP/1.1" 200 40 "-" "curl/7.68.0"

curl  http://nginx-handbook.test/
# this will be logged to the default file.

sudo cat /var/log/nginx/access.log 
# 192.168.20.20 - - [25/Apr/2021:11:15:14 +0000] "GET / HTTP/1.1" 200 41 "-" "curl/7.68.0"

Với ví dụ này, chúng ta có thể rõ được cách vận hành của việc ghi log đã hoạt động đúng với thiết lập.

Lcog errors

Theo một cách khác, việc ghi log lỗi của nginx được mặc định ghi vào file error.log

Hãy theo dõi ví dụ sau

events {
}

http {
  include /etc/nginx/mime.types;

  server {
    listen 80;
    server_name nglearns.test;
    return 200 "..." "...";
  }
}

Trong trường hợp này, ta đã return về 2 giá trị thay vì một, vì lý do này, hệ thống nginx sẽ không hoạt động đúng và sẽ trả ra lỗi.

Thực nghiệm :

Bước 1 : reload lại hệ thống

sudo nginx -s reload

Bước 2 : Kiểm tra file log

sudo nginx -s reload

Ngay lập tức, hệ thống sẽ hiển thị thông báo lỗi như sau

# nginx: [emerg] invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

Bước 3 : kiểm tra lỗi đã được ghi lại

sudo cat /var/log/nginx/error.log 

kết quả

# 2021/04/25 08:35:45 [notice] 4169#4169: signal process started
# 2021/04/25 10:03:18 [emerg] 8434#8434: invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

Độ ưu tiên

Việc gặp phải log lỗi đa phần không gây hại cho hệ thống, tuy nhiên khi gặp lỗi emerg thì cần phải xử lý ngay vì đây là lỗi nghiêm trọng.

Sau đây là một số cấp độ cần phải biết khi làm việc với log lỗi:

• debug : là những log lỗi cơ bản thường sẽ đi kèm với số dòng bị lỗi
• info : là những thông tin không thực sự cần thiết, nhưng sẽ tốt hơn nếu biết về nó
• notice : là những lỗi thường gặp, cần được chú ý tới
• warn : là những lội không mong đợi, tuy nhiên nó không đáng để quan ngại
• error : là những lỗi của một hành vi thực hiện không thành công, cần phải sửa chữa để đảm bảo hệ thống chạy ổn định
• crit : là những lỗi cần được giải quyết một cách nghiêm túc
• alert : là những lỗi cần phải fix càng sớm càng tốt
• emerg : là những lỗi cực kỳ nguy hiểm, cần phải sửa ngay lập tức

Trên thực tế, việc kiếm soát độ ưu tiên của log là hoàn toàn có thể, hãy tham khảo ví dụ sau

events {
}

http {
  include /etc/nginx/mime.types;
  server {
    listen 80;
    server_name nglearns.test;
  error_log /var/log/error.log warn;
    return 200 "..." "...";
  }
}

Trong ví dụ này, ta đã thành công trong việc ghi log với độ ưu tiên là warn