Thứ tư, 21/06/2017 | 00:00 GMT+7

Cách thêm module log vào Nginx trên Debian 8

Quản trị server không chỉ là cấu hình ban đầu của các dịch vụ. Nó cũng liên quan đến việc giám sát các dịch vụ đó và đảm bảo chúng hoạt động trơn tru nhất có thể. Một trong những nguồn kiến thức quan trọng nhất đối với administrator là các file log , chứa thông tin về các sự kiện hệ thống.

Trong trường hợp web server , như Nginx, log chứa thông tin có giá trị về mỗi lần cố gắng truy cập tài nguyên thông qua web server . Mỗi khách truy cập trang web và hình ảnh được xem hoặc file được download đều được ghi lại một cách tỉ mỉ trong log . Khi lỗi xảy ra, chúng cũng sẽ được lưu trong log . Sẽ dễ dàng hơn nhiều khi làm việc với các file log có cấu trúc tốt.

Trong hướng dẫn này, ta sẽ xem xét cách sử dụng module ghi log của Nginx. Ta sẽ cài đặt các file log riêng biệt cho các khối server khác nhau và sau đó tùy chỉnh kết quả ghi log . Ta cũng sẽ thêm thông tin bổ sung về các yêu cầu (trong ví dụ của hướng dẫn này, thời gian cần thiết để gửi một yêu cầu) vào log truy cập ngoài những gì Nginx bao gồm theo mặc định.

Yêu cầu

Để làm theo hướng dẫn này, bạn cần :

Bước 1 - Tạo file kiểm tra

Trong bước này, ta sẽ tạo một số file thử nghiệm trong folder trang web Nginx mặc định. Ta sẽ sử dụng những thứ này để kiểm tra cấu hình ghi log của ta .

Khi Nginx (hoặc bất kỳ web server nào khác) nhận được yêu cầu HTTP cho một file , nó sẽ mở file đó và phân phát file đó cho user bằng cách truyền nội dung của nó qua mạng. Tệp càng nhỏ thì càng truyền nhanh. Khi file được chuyển đầy đủ, yêu cầu được coi là hoàn tất và chỉ sau đó quá trình chuyển mới được ghi lại.

Phần sau của hướng dẫn này, ta sẽ sửa đổi cấu hình ghi log để bao gồm thông tin hữu ích về lượng thời gian mỗi yêu cầu mất. Cách dễ nhất để kiểm tra cấu hình đã sửa đổi và nhận thấy sự khác biệt giữa các yêu cầu khác nhau là tạo một số file thử nghiệm có kích thước khác nhau sẽ được truyền trong repository ảng thời gian khác nhau.

Hãy tạo một file 1 megabyte có tên 1mb.test trong folder Nginx mặc định bằng cách sử dụng truncate .

  • sudo truncate -s 1M /var/www/html/1mb.test

Tương tự, hãy tạo thêm hai file có kích thước khác nhau, đầu tiên là 10 và sau đó là 100 megabyte, đặt tên chúng cho phù hợp.

  • sudo truncate -s 10M /var/www/html/10mb.test
  • sudo truncate -s 100M /var/www/html/100mb.test

Cuối cùng nhưng không kém phần quan trọng, hãy tạo một file trống:

  • sudo touch /var/www/html/empty.test

Ta sẽ sử dụng các file này trong bước tiếp theo để điền vào file log với cấu hình mặc định và sau đó trong hướng dẫn để chứng minh cấu hình tùy chỉnh.

Bước 2 - Hiểu cấu hình mặc định

Mô-đun log là một module Nginx cốt lõi, nghĩa là nó không cần phải được cài đặt riêng để được sử dụng. Tuy nhiên, cấu hình mặc định là mức tối thiểu. Trong bước này, ta sẽ xem cấu hình mặc định hoạt động như thế nào.

Khi cài đặt mới, Nginx ghi lại tất cả các yêu cầu vào hai file riêng biệt: log truy cập và log lỗi. Nhật ký lỗi, nằm trong /var/log/nginx/error.log , lưu trữ thông tin về lỗi server bất thường hoặc lỗi trong quá trình xử lý yêu cầu.

Nhật ký truy cập, nằm trong /var/log/nginx/access.log , được sử dụng thường xuyên hơn. Đó là nơi lưu giữ thông tin về tất cả các yêu cầu đối với Nginx. Trong log này, bạn có thể thấy, trong số những thứ khác, user đang truy cập file nào, trình duyệt web nào họ đang sử dụng, địa chỉ IP nào họ có và mã trạng thái HTTP nào mà Nginx phản hồi với mỗi yêu cầu.

Hãy xem dòng ví dụ của file log truy cập trông như thế nào. Trước tiên, hãy yêu cầu file trống mà ta đã tạo ở Bước 1 từ Nginx để file log không bị trống.

  • curl -i http://localhost/empty.test

Đáp lại, bạn sẽ thấy một số tiêu đề phản hồi HTTP:

Tiêu đề phản hồi Nginx
HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Fri, 09 Dec 2016 23:05:18 GMT Content-Type: application/octet-stream Content-Length: 0 Last-Modified: Fri, 09 Dec 2016 23:05:13 GMT Connection: keep-alive ETag: "584b38a9-0" Accept-Ranges: bytes 

Từ phản hồi này, bạn có thể học được một số điều:

  • HTTP/1.1 200 OK cho ta biết rằng Nginx đã phản hồi với mã trạng thái 200 OK cho ta biết không có lỗi.
  • Content-Length: 0 nghĩa là tài liệu trả về có độ dài bằng 0.
  • Yêu cầu được xử lý vào Fri, 09 Dec 2016 23:05:18 GMT .

Hãy xem điều này có trùng với những gì Nginx lưu trữ trong log truy cập của nó hay không. Các file log chỉ có thể đọc được bởi admin-user , vì vậy phải sử dụng sudo để truy cập chúng.

  • sudo tail /var/log/nginx/access.log

Nhật ký sẽ có một dòng như thế này, tương ứng với yêu cầu kiểm tra mà ta đã đưa ra trước đó.

Truy cập mục log
127.0.0.1 - - [09/Dec/2016:23:07:02 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.38.0" 

Nginx sử dụng Định dạng log kết hợp , là định dạng chuẩn hóa của log truy cập thường được các web server sử dụng để có khả năng tương tác. Ở định dạng này, mỗi phần thông tin được phân cách bằng một khoảng trắng; dấu gạch nối thể hiện phần thông tin còn thiếu.

Từ trái sang phải, các danh mục là:

  • Địa chỉ IP của user đã yêu cầu tài nguyên. Vì bạn đã sử dụng curl local , địa chỉ trỏ đến server local , 127.0.0.1 .

  • Thông tin ghi log từ xa . Đây sẽ luôn là dấu gạch ngang ở đây vì Nginx không hỗ trợ thông tin này.

  • Tên user của user đã đăng nhập theo Xác thực cơ bản HTTP. Điều này sẽ trống cho tất cả các yêu cầu ẩn danh.

  • Ngày yêu cầu . Bạn có thể thấy điều này trùng với ngày từ tiêu đề phản hồi của ta .

  • Đường dẫn yêu cầu , bao gồm phương thức yêu cầu ( GET ), đường dẫn đến file được yêu cầu ( /empty.text ) cũng như giao thức được sử dụng ( HTTP/1.1 ).

  • Mã trạng thái phản hồi , là 200 OK , nghĩa là thành công.

  • Độ dài của file đã chuyển , ở đây là 0 vì file trống.

  • Tiêu đề HTTP Referer , chứa địa chỉ của tài liệu nơi yêu cầu bắt nguồn. Trong ví dụ này, nó trống, nhưng nếu đây là một file hình ảnh, người tham chiếu sẽ trỏ đến trang mà hình ảnh được sử dụng.

    Tiêu đề HTTP Referer là lỗi chính tả của từ “liên kết giới thiệu”, trở lại nguồn root của HTTP và là một phần của tiêu chuẩn HTTP.

  • Các tác nhân user , đó là curl đây.

Ngay cả một mục nhập log duy nhất trong log truy cập cũng chứa rất nhiều thông tin có giá trị về một yêu cầu. Tuy nhiên, có một thông tin quan trọng còn thiếu. Mặc dù ta đã yêu cầu vị trí chính xác của http://localhost/empty.test , nhưng chỉ có đường dẫn đến file /empty.test là trong mục log ; thông tin về tên server (ở đây, server localhost ) bị mất.

Bước 3 - Cấu hình Nhật ký Truy cập Riêng biệt

Tiếp theo, ta sẽ overrides cấu hình ghi log mặc định (nơi Nginx lưu trữ một file log truy cập cho tất cả các yêu cầu) và đặt Nginx thay vào đó lưu trữ file log riêng biệt cho khối server mặc định đi kèm với cài đặt Nginx sạch. Bạn có thể làm quen với khối server Nginx bằng cách đọc hướng dẫn Cách cài đặt khối server Nginx trên Debian 7 .

Một thực tiễn tốt là lưu trữ các file log riêng biệt cho từng khối server , tách các log từ các trang web khác nhau một cách hiệu quả. Điều này không chỉ làm cho các file log nhỏ hơn mà còn giúp cho việc phân tích log dễ dàng hơn để phát hiện lỗi và hoạt động đáng ngờ.

Để thay đổi cấu hình khối server Nginx mặc định, hãy mở file cấu hình Nginx khối server trong nano hoặc editor yêu thích của bạn.

  • sudo nano /etc/nginx/sites-available/default

Tìm đoạn cấu hình server , trông giống như sau:

/ etc / nginx / sites-available / default
. . . # Default server configuration #  server {     listen 80 default_server;     listen [::]:80 default_server;  . . . 

và thêm hai dòng được đánh dấu màu đỏ vào cấu hình:

/ etc / nginx / sites-available / default
. . . # Default server configuration #  server {     listen 80 default_server;     listen [::]:80 default_server;      access_log /var/log/nginx/default-access.log;     error_log /var/log/nginx/default-error.log; . . . 

Chỉ thị access_log đặt đường dẫn đến file nơi các bản ghi truy cập sẽ được lưu trữ và error_log cũng làm như vậy đối với log lỗi. Ta sử dụng cùng một folder làm log Nginx mặc định ( /var/log/nginx ), nhưng với các tên file khác nhau. Nếu bạn có nhiều khối server , bạn nên đặt tên file log theo cách nhất quán và có ý nghĩa, giống như sử dụng domain trong tên file .

Lưu file để thoát.

Lưu ý: Lưu ý để duy trì các file log riêng biệt cho từng khối server , bạn phải áp dụng thay đổi cấu hình nói trên mỗi khi tạo khối server mới trong cấu hình Nginx của bạn .

Để kích hoạt cấu hình mới, hãy khởi động lại Nginx.

  • sudo systemctl restart nginx.service

Để kiểm tra cấu hình mới, hãy thực hiện cùng một yêu cầu cho file thử nghiệm trống của ta như trước đây.

  • curl -i http://localhost/empty.test

Kiểm tra đảm bảo rằng dòng log giống với dòng mà ta đã thấy trước đó được ghi vào file riêng biệt mà ta vừa cấu hình .

  • sudo tail /var/log/nginx/default-access.log

Trong bước tiếp theo, ta sẽ tùy chỉnh định dạng log trong file mới này và bao gồm thông tin bổ sung.

Bước 4 - Cấu hình định dạng log tùy chỉnh

Tại đây, ta sẽ cài đặt định dạng ghi log tùy chỉnh để làm cho thông tin bổ sung log Nginx (yêu cầu mất bao lâu để được xử lý) và cấu hình khối server mặc định để sử dụng định dạng mới này.

Ta cần xác định định dạng log mới trước khi nó được dùng . Trong Nginx, mỗi định dạng log có một tên duy nhất, tên này là chung cho toàn bộ server . Các khối server riêng lẻ có thể được cấu hình để sử dụng các định dạng đó sau này chỉ bằng cách tham khảo tên của chúng.

Để xác định định dạng ghi log mới, hãy tạo một file cấu hình mới có tên là timed-log-format.conf trong folder cấu hình bổ sung Nginx.

  • sudo nano /etc/nginx/conf.d/timed-log-format.conf

Thêm các nội dung sau:

/etc/nginx/conf.d/timed-log-format.conf
log_format timed '$remote_addr - $remote_user [$time_local] '                  '"$request" $status $body_bytes_sent '                  '"$http_referer" "$http_user_agent" $request_time'; 

Lưu file để thoát.

Chỉ thị cài đặt log_format xác định định dạng log mới. Phần tử tiếp theo là số nhận dạng duy nhất của định dạng này; ở đây ta đang sử dụng hẹn giờ , nhưng bạn có thể chọn bất kỳ tên nào.

Tiếp theo là định dạng bản ghi, được chia thành ba dòng để dễ đọc. Nginx hiển thị thông tin về tất cả các yêu cầu trong các biến hệ thống được đặt tên trước ký hiệu đô la. Chúng sẽ được thay thế bằng thông tin thực tế về yêu cầu trong khi ghi chi tiết yêu cầu vào log truy cập (ví dụ: $request_addr sẽ được thay thế bằng địa chỉ IP của khách truy cập).

Định dạng ở trên giống với Định dạng log chung đã thảo luận trước đó với một điểm khác biệt: việc bổ sung biến hệ thống $request_time ở cuối. Nginx sử dụng biến này để lưu trữ thời gian yêu cầu tính bằng mili giây và bằng cách sử dụng biến này ở định dạng log của ta , ta yêu cầu Nginx ghi thông tin đó vào file log .

Bây giờ ta có một định dạng log tùy chỉnh có tên là thời gian được xác định trong cấu hình Nginx, nhưng khối server mặc định chưa sử dụng định dạng này. Tiếp theo, mở file cấu hình Nginx của khối server .

  • sudo nano /etc/nginx/sites-available/default

Tìm các server đoạn cấu hình mà ta sửa đổi trước đó và thêm timed tên định dạng log vào access_log cài đặt như tô sáng bên dưới màu đỏ:

/ etc / nginx / sites-available / default
. . . # Default server configuration #  server {     listen 80 default_server;     listen [::]:80 default_server;      access_log /var/log/nginx/default-access.log timed;     error_log /var/log/nginx/default-error.log; . . . 

Lưu file để thoát.

Để kích hoạt cấu hình mới, hãy khởi động lại Nginx.

  • sudo systemctl restart nginx.service

Bây giờ mọi thứ đã được cài đặt , hãy kiểm tra xem nó có hoạt động không.

Bước 5 - Xác minh cấu hình mới

Ta có thể kiểm tra cấu hình mới bằng cách gọi một số yêu cầu tới Nginx với curl , giống như ta đã làm trong bước 2. Lần này, ta sẽ sử dụng các file mẫu được tạo ở bước 1:

  • curl -i http://localhost/empty.test
  • curl -i http://localhost/1mb.test
  • curl -i http://localhost/10mb.test
  • curl -i http://localhost/100mb.test

Bạn sẽ nhận thấy rằng mỗi lệnh tiếp theo sẽ mất nhiều thời gian hơn để thực thi, vì các file lớn hơn và cần nhiều thời gian hơn để chuyển chúng.

Hãy hiển thị log truy cập sau khi thực hiện các yêu cầu đó.

  • sudo tail /var/log/nginx/default-access.log

Nhật ký bây giờ sẽ chứa nhiều dòng hơn, nhưng bốn dòng cuối cùng sẽ tương ứng với các yêu cầu kiểm tra mà bạn vừa thực hiện.

Truy cập các mục log
127.0.0.1 - - [09/Dec/2016:23:07:02 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.38.0" 127.0.0.1 - - [09/Dec/2016:23:08:28 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.38.0" 0.000 127.0.0.1 - - [09/Dec/2016:23:08:28 +0000] "GET /1mb.test HTTP/1.1" 200 1048576 "-" "curl/7.38.0" 0.000 127.0.0.1 - - [09/Dec/2016:23:08:28 +0000] "GET /10mb.test HTTP/1.1" 200 10485760 "-" "curl/7.38.0" 0.302 127.0.0.1 - - [09/Dec/2016:23:08:39 +0000] "GET /100mb.test HTTP/1.1" 200 68516844 "-" "curl/7.38.0" 7.938 

Bạn sẽ thấy rằng các đường dẫn khác nhau mỗi lần, hiển thị tên file chính xác và kích thước yêu cầu tăng lên mỗi lần. Phần quan trọng là số được đánh dấu cuối cùng, đó là thời gian xử lý yêu cầu tính bằng mili giây mà ta vừa cấu hình ở định dạng log tùy chỉnh của bạn . Như bạn mong đợi, file càng lớn thì thời gian chuyển càng lâu.

Nếu đúng như vậy, bạn đã cấu hình định dạng log tùy chỉnh trong Nginx thành công!

Kết luận

Mặc dù không đặc biệt hữu ích khi thấy rằng các file lớn hơn mất nhiều thời gian để truyền hơn, nhưng thời gian xử lý yêu cầu có thể rất hữu ích khi Nginx được sử dụng để phục vụ các trang web động. Nó được dùng để theo dõi các node thắt cổ chai trong trang web và dễ dàng tìm thấy các yêu cầu mất nhiều thời gian hơn bình thường.

$request_time chỉ là một trong nhiều biến hệ thống mà Nginx tiết lộ được dùng trong cấu hình ghi log tùy chỉnh. Những người khác bao gồm, ví dụ, giá trị của các tiêu đề phản hồi được gửi cùng với phản hồi cho khách hàng. Việc thêm các biến khác vào định dạng log cũng dễ dàng như đặt chúng vào chuỗi định dạng log giống như ta đã làm với $request_time . Nó là một công cụ mạnh mẽ mà bạn có thể sử dụng để làm lợi thế của bạn trong khi cấu hình ghi log cho các trang web của bạn .

Danh sách các biến được dùng với các định dạng log Nginx được mô tả trong tài liệu module log của Nginx .


Tags:

Các tin liên quan

Cách triển khai ứng dụng Laravel với Nginx trên Ubuntu 16.04
2017-06-14
Cách bảo mật CI bằng SSL bằng Nginx trên Ubuntu 16.04
2017-05-26
Cách cấu hình Buildbot với SSL bằng Nginx Reverse Proxy
2017-05-17
Cách cấu hình Jenkins với SSL bằng cách sử dụng Nginx Reverse Proxy
2017-05-02
Cách tạo chứng chỉ SSL tự ký cho Nginx trên CentOS 7
2017-01-09
Cách thiết lập Django với Postgres, Nginx và Gunicorn trên Debian 8
2016-12-22
Cách tạo chứng chỉ SSL tự ký cho Nginx trên Debian 8
2016-12-20
Cách bảo mật Nginx bằng Let's Encrypt trên Debian 8
2016-12-19
Cách cung cấp các ứng dụng Django với uWSGI và Nginx trên Debian 8
2016-12-19
Cách tạo chuyển hướng tạm thời và vĩnh viễn với Nginx
2016-12-19