Thứ ba, 20/08/2013 | 00:00 GMT+7

Cách cấu hình ghi log và xoay vòng log trong Nginx trên VPS Ubuntu


Đăng nhập Nginx

Một trong những cách dễ nhất để bạn tự tránh gặp rắc rối với web server của bạn là cấu hình ghi log thích hợp ngay hôm nay. Thông tin ghi log trên server của bạn cung cấp cho bạn quyền truy cập vào dữ liệu sẽ giúp bạn khắc phục sự cố và đánh giá các tình huống khi chúng phát sinh.

Trong bài viết này, ta sẽ xem xét khả năng ghi log của Nginx và khám phá cách cấu hình các công cụ này để phục vụ tốt nhất nhu cầu của bạn. Trong hướng dẫn này, ta sẽ sử dụng VPS Ubuntu 12.04 làm ví dụ, nhưng bất kỳ bản phân phối hiện đại nào cũng phải hoạt động theo cách tương tự.

Chỉ thị Error_log

Nginx sử dụng một số chỉ thị khác nhau để kiểm soát việc ghi log hệ thống. Một trong những module lõi được gọi là "error_log".

Cú pháp Error_log

Chỉ thị "error_log" được sử dụng để xử lý ghi log các thông báo lỗi chung. Nếu bạn đến từ Apache, điều này rất giống với chỉ thị "ErrorLog" của Apache.

Lệnh error_log có cú pháp sau:

error_log log_file [ log_level ]

"Log_file" trong ví dụ chỉ định file nơi các bản ghi sẽ được ghi. "Log_level" chỉ định mức ghi log thấp nhất mà bạn muốn ghi lại.

Mức độ ghi log

Chỉ thị error_log có thể được cấu hình để ghi nhiều hơn hoặc ít hơn thông tin theo yêu cầu. Mức độ ghi log có thể là bất kỳ mức nào sau đây:

  • emerg: các tình huống khẩn cấp mà hệ thống đang trong trạng thái không sử dụng được.
  • cảnh báo : Tình huống nghiêm trọng cần hành động kịp thời.
  • crit : Những vấn đề quan trọng cần được giải quyết.
  • error : Đã xảy ra lỗi. Một cái gì đó đã không thành công.
  • cảnh báo : Có điều gì đó bất thường đã xảy ra, nhưng không phải là nguyên nhân đáng lo ngại.
  • thông báo : Một cái gì đó bình thường, nhưng đáng chú ý đã xảy ra.
  • info : Một tin nhắn thông tin có thể rất tốt nếu bạn biết.
  • gỡ lỗi : Thông tin gỡ lỗi có thể hữu ích để xác định vị trí sự cố đang xảy ra.

Các cấp cao hơn trong danh sách được coi là ưu tiên cao hơn. Nếu bạn chỉ định một cấp độ, log sẽ ghi lại cấp độ đó và bất kỳ cấp độ nào cao hơn cấp độ đã chỉ định.

Ví dụ: nếu bạn chỉ định "lỗi", log sẽ ghi lại các thông báo có nhãn "lỗi", "crit", "cảnh báo" và "khẩn cấp".

Ta có thể thấy lệnh này đang được sử dụng nếu ta xem trong file cấu hình chính:

sudo nano /etc/nginx/nginx.conf
. . .
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
. . .

Nếu bạn không muốn error_log ghi lại bất kỳ thứ gì, bạn phải gửi kết quả vào "/ dev / null":

error_log /dev/null crit;

Chỉ thị ghi log khác mà ta thấy ở trên, chỉ thị "access_log", sẽ được thảo luận trong phần tiếp theo.

Hướng dẫn ghi log HttpLogModule

Trong khi chỉ thị error_log là một phần của module cốt lõi, thì chỉ thị access_log là một phần của HttpLogModule. Nó cung cấp khả năng tùy chỉnh log .

Có một số chỉ thị khác có trong module này để hỗ trợ việc cấu hình log tùy chỉnh.

Chỉ thị Log_format

Chỉ thị log_format được sử dụng để mô tả định dạng của mục nhập log sử dụng văn bản thuần túy và các biến.

Có một định dạng được định nghĩa với Nginx được gọi là "kết hợp". Đây là định dạng phổ biến được nhiều server sử dụng.

Đây là định dạng kết hợp sẽ trông như thế nào nếu nó không được xác định bên trong và cần được chỉ định bằng chỉ thị log_format:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Định nghĩa này kéo dài nhiều dòng cho đến khi nó tìm thấy dấu chấm phẩy (;).

Các phần bắt đầu bằng dấu đô la ($) biểu thị các biến, trong khi các ký tự như "-", "[" và "]" được hiểu theo nghĩa đen.

Cú pháp chung của lệnh là:

log_format format_name string_describing_formatting;

Bạn có thể sử dụng các biến được hỗ trợ bởi module cốt lõi để tạo chuỗi ghi log của bạn .

Chỉ thị Access_log

Lệnh access_log sử dụng một số cú pháp tương tự với lệnh error_log, nhưng linh hoạt hơn. Nó được sử dụng để cấu hình ghi log tùy chỉnh.

Lệnh access_log sử dụng cú pháp sau:

access_log /path/to/log/location [ format_of_log buffer_size ];

Giá trị mặc định cho access_log là định dạng "kết hợp" mà ta đã thấy trong phần log_format. Bạn có thể sử dụng bất kỳ định dạng nào được xác định bởi định nghĩa log_format.

Kích thước cache là kích thước tối đa của dữ liệu mà Nginx sẽ giữ trước khi ghi tất cả vào log . Bạn cũng có thể chỉ định nén file log bằng cách thêm "gzip" vào định nghĩa:

access_log location format gzip;

Không giống như chỉ thị error_log, nếu bạn không muốn ghi log , bạn có thể tắt nó bằng cách chỉ định:

access_log off;

Không cần thiết phải viết thành "/ dev / null" trong trường hợp này.

Xoay log

Khi các file log phát triển, điều cần thiết là phải quản lý các cơ chế ghi log để tránh làm đầy dung lượng đĩa. Xoay log là quá trình chuyển đổi các file log và có thể lưu trữ các file cũ trong một khoảng thời gian nhất định.

Nginx không cung cấp công cụ để quản lý file log , nhưng nó bao gồm các cơ chế giúp việc xoay log trở nên đơn giản.

Xoay log thủ công

Nếu bạn muốn xoay log của bạn theo cách thủ công (hoặc nhiều khả năng hơn, tạo một tập lệnh để xoay chúng), bạn có thể làm như vậy theo ví dụ trong wiki Nginx:

mv /path/to/access.log /path/to/access.log.0
kill -USR1 `cat /var/run/nginx.pid`
sleep 1
[ post-rotation processing of old log file ]

Đầu tiên, ta di chuyển log hiện tại sang một file mới để lưu trữ. Một schemas phổ biến là đặt tên file log mới nhất với hậu tố là ".0", sau đó đặt tên file cũ hơn bằng ".1", v.v.

Lệnh thực sự xoay các bản ghi là "kill -USR1 /var/run/nginx.pid". Điều này không giết quá trình Nginx, nhưng thay vào đó, nó sẽ gửi tín hiệu khiến nó reload các file log của bạn . Điều này sẽ khiến các yêu cầu mới được ghi vào file log được làm mới.

Tệp "/var/run/nginx.pid" là nơi Nginx lưu trữ pid của quy trình chính. Nó được chỉ định trong file cấu hình với một dòng bắt đầu bằng "pid":

sudo nano /etc/nginx/nginx.conf
. . .
pid /path/to/pid/file;
. . .

Sau khi xoay vòng, ta thực hiện "ngủ 1" để cho phép quá trình hoàn tất quá trình chuyển. Sau đó, ta có thể nén các file cũ hoặc thực hiện bất kỳ quy trình hậu kỳ nào mà ta muốn.

Log Rotation với logrotate

Ứng dụng logrotate là một chương trình đơn giản để xoay các bản ghi. Nó được cài đặt trên Ubuntu theo mặc định và Nginx trên Ubuntu đi kèm với tập lệnh logrotate tùy chỉnh.

Ta có thể thấy tập lệnh xoay vòng log bằng lệnh :

sudo nano /etc/logrotate.d/nginx

Dòng đầu tiên của file chỉ định vị trí mà các dòng tiếp theo sẽ áp dụng. Hãy nhớ điều này nếu bạn chuyển đổi vị trí đăng nhập các file cấu hình Nginx.

Phần còn lại của file chỉ định rằng các bản ghi sẽ được luân phiên hàng ngày và 52 bản sao cũ hơn sẽ được giữ nguyên. Cấu hình chung của logrotate nằm ngoài phạm vi của bài viết này.

Ta có thể thấy rằng phần "postrotate" chứa một lệnh tương tự như các cơ chế xoay thủ công mà ta đang sử dụng:

postrotate
	[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript

Phần này yêu cầu Nginx reload các file log sau khi quá trình quay hoàn tất.

Kết luận

Cấu hình và quản lý log phù hợp có thể giúp bạn tiết kiệm thời gian và năng lượng trong trường hợp server của bạn gặp sự cố. Việc dễ dàng tiếp cận thông tin giúp bạn chẩn đoán sự cố có thể là sự khác biệt giữa cách khắc phục tầm thường và cơn đau đầu dai dẳng.

Điều quan trọng là phải theo dõi log server để duy trì một trang hoạt động và đảm bảo bạn không để lộ thông tin nhạy cảm. Hướng dẫn này chỉ nên dùng như một phần giới thiệu về trải nghiệm của bạn với việc ghi log .

Bởi Justin Ellingwood

Tags:

Các tin liên quan

Cách cài đặt và cấu hình Django với Postgres, Nginx và Gunicorn
2013-08-14
Cách phát trực tuyến video với Nginx và JWPlayer trên CentOS 6
2013-05-31
Cách thiết lập xác thực HTTP với Nginx trên Ubuntu 12.10
2013-04-30
Cách cài đặt (LEMP) nginx, MySQL, PHP stack trên Arch Linux
2012-11-02
Cách thiết lập cân bằng tải Nginx
2012-08-27
Cách cấu hình Nginx làm Reverse Proxy cho Apache
2012-07-20
Cách cài đặt WordPress với nginx trên CentOS 6
2012-07-02
Cách cài đặt WordPress với nginx trên CentOS 6
2012-07-02
Cách tạo chứng chỉ SSL trên nginx cho CentOS 6
2012-06-08
Cách thiết lập server ảo nginx (server block) trên CentOS 6
2012-06-07