如何在Debian 8上将日志模块添加到Nginx

介绍

服务器管理不仅仅是关于服务的初始配置。 它还涉及监督这些服务，并确保它们运行顺利。 管理员最重要的知识来源之一是日志文件，其中包含有关系统事件的信息。

对于像Nginx这样的Web服务器，日志包含有关通过Web服务器访问资源的每次尝试的有价值信息。 每个网站的访问者和图像被看到或文件下载被精心地注册在日志中。 当错误发生时，它们也将保存在日志中。 使用结构良好的日志文件更容易。

在本指南中，我们将介绍如何使用Nginx的日志记录模块。 我们将为不同的服务器块设置单独的日志文件，然后自定义日志输出。 我们还将在默认情况下添加关于请求的其他信息（在本教程的示例中，提供请求所需的时间）到访问日志。

先决条件

要遵循本教程，您将需要：

• 一个Debian 8服务器设置了这个初始服务器设置教程 ，包括一个sudo非root用户。

• Nginx安装在您的服务器上，遵循如何在Debian 8教程中安装Nginx 。

第1步 - 创建测试文件

在这一步中，我们将在默认的Nginx网站目录中创建几个测试文件。 我们将使用这些来测试我们的日志配置。

当Nginx（或任何其他Web服务器）收到文件的HTTP请求时，它会打开该文件，并通过网络传送其内容来向用户提供该文件。 文件越小，传输速度就越快。 当文件完整传输时，该请求被认为是完整的，只有这样才被传输。

在本教程的后面，我们将修改日志记录配置，以包括有关每个请求需要多少时间的有用信息。 测试修改的配置并注意不同请求之间的差异的最简单方法是创建不同大小的几个测试文件，这些测试文件将以不同的时间量传输。

让我们使用truncate在默认的Nginx目录下创建一个名为1mb.test的1兆字节文件。

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

同样，我们再创建两个不同大小的文件，前10个，然后是100兆字节，相应地命名它们。

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

最后但并非最不重要的是，我们也创建一个空文件：

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

我们将在下一步中使用这些文件来使用默认配置填充日志文件，然后在本教程中稍后介绍自定义配置。

第2步 - 了解默认配置

日志模块是一个核心的Nginx模块，这意味着它不需要单独安装使用。 然而，默认配置是最小的。 在此步骤中，我们将看到默认配置如何工作。

在新的安装中，Nginx将所有请求记录到两个单独的文件：访问日志和错误日志。 位于/var/log/nginx/error.log的错误日志存储有关异常服务器错误或处理请求中的错误的信息。

访问日志位于/var/log/nginx/access.log ，更常用。 这是关于所有Nginx请求的信息。 在这个日志中，您可以看到用户正在访问哪些文件，他们正在使用哪些Web浏览器，他们拥有哪些IP地址，哪些HTTP状态代码Nginx对每个请求做出响应。

让我们看看访问日志文件的一个示例行是什么样的。 首先，请求从Nginx在第1步中创建的空文件，以便日志文件不会为空。

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

作为响应，您应该看到几个HTTP响应标头：

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

从这个回应，你可以学到几件事情：

• HTTP/1.1 200 OK告诉我们，Nginx回复了200 OK状态代码，告诉我们没有错误。
• Content-Length: 0表示返回的文档为零长度。
• 该请求已于Fri, 09 Dec 2016 23:05:18 GMT 。

让我们看看这是否匹配了Nginx存储在其访问日志中的内容。 日志文件只能由管理用户读取，因此必须使用sudo来访问它们。

sudo tail /var/log/nginx/access.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使用组合日志格式 ，它是Web服务器通常用于互操作性的访问日志的标准格式。 以这种格式，每条信息都由一个空格分隔; 连字符表示丢失的信息。

从左到右，类别是：

• 请求资源的用户的IP地址 。 因为你在本地使用curl ，所以地址指向本地主机127.0.0.1 。

• 远程记录信息。 这将永远是连字符，因为Nginx不支持此信息。

• 根据HTTP基本认证登录用户的用户名 。 所有匿名请求都将为空。

• 请求日期 。 您可以看到这与我们的响应标头的日期相匹配。

• 请求路径 ，包括请求方法（ GET ），请求文件的路径（ /empty.text ）以及使用的协议（ HTTP/1.1 ）。

• 响应状态码是200 OK ，意思是成功。

• 传输文件的长度，因为文件为空，这里为0 。

• HTTP Referer头 ，其中包含发起请求的文档的地址。 在这个例子中，它是空的，但是如果这是一个图像文件，引用者将指向使用该图像的页面。

  HTTP Referer标题是“referrer”一词的拼写错误，可以追溯到HTTP的起源，并且是HTTP标准的一部分。

• 用户代理 ，在这里curl 。

即使访问日志中的单个日志条目包含有关请求的大量有价值的信息。 但是，有一点重要的信息丢失。 当我们请求http://localhost/empty.test的确切位置时，只有/empty.test文件的路径在日志条目中; 有关主机名（这里是localhost ）的信息将丢失。

第3步 - 配置单独的访问日志

接下来，我们将覆盖默认的日志记录配置（Nginx存储所有请求的一个访问日志文件），并使Nginx替代为干净的Nginx安装附带的默认服务器块存储单独的日志文件。 您可以通过阅读Debian 7教程中如何设置 Nginx服务器块来了解Nginx服务器块。

为每个服务器块存储单独的日志文件是一个很好的做法，有效地将来自不同网站的日志隔离开来。 这不仅使日志文件更小，但重要的是使日志更容易分析以发现错误和可疑活动。

要更改默认的Nginx服务器块配置，请打开nano的服务器块Nginx配置文件或您喜欢的文本编辑器。

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

查找server配置块，如下所示：

. . .
# Default server configuration
#

server {
    listen 80 default_server;
    listen [::]:80 default_server;

. . .

并将标有红色的两行添加到配置中：

. . .
# 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;
. . .

access_log指令将存储访问日志的路径设置为文件，并且error_log对错误日志执行相同操作。 我们使用与默认的Nginx日志（ /var/log/nginx ）相同的目录，但使用不同的文件名。 如果您有多个服务器块，最好以一致和有意义的方式命名日志文件，例如在文件名中使用域名。

保存并关闭文件以退出。

注意：请记住，为了为每个服务器块维护单独的日志文件，您必须在每次在Nginx配置中创建新服务器块时应用上述配置更改。

要启用新配置，请重新启动Nginx。

sudo systemctl restart nginx.service

要测试新配置，请像以前一样对我们的空测试文件执行相同的请求。

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

检查与我们之前看到的日志行相同的日志行被写入我们刚刚配置的单独文件。

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

在下一步中，我们将自定义此新文件中日志的格式，并包含其他信息。

第4步 - 配置自定义日志格式

在这里，我们将设置一个自定义日志记录格式，使Nginx记录附加信息（请求处理多长时间），并配置默认服务器块以使用此新格式。

我们需要在使用之前定义新的日志格式。 在Nginx中，每个日志格式都有一个唯一的名称，它是整个服务器的全局名称。 单个服务器块可以配置为稍后通过引用其名称来使用这些格式。

要定义新的日志记录格式，请在Nginx extra配置目录中创建一个名为timed-log-format.conf的新配置文件。

sudo nano /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';

保存并关闭文件以退出。

log_format设置指令定义新的日志格式。 下一个元素是此格式的唯一标识符; 这里我们使用的是时间 ，但您可以选择任何名称。

接下来是日志格式本身，分为三行可读性。 Nginx在美元符号之前的命名系统变量中公开有关所有请求的信息。 在将请求详细信息写入访问日志（例如， $request_addr将被访问者的IP地址替换）时，这些将被替换为关于请求的实际信息。

上面的格式与前面讨论过的普通日志格式是一样的：在最后添加$request_time系统变量。 Nginx使用此变量来存储请求所花费的时间（以毫秒为单位），并且以日志格式使用此变量，我们告诉Nginx将该信息写入日志文件。

现在我们在Nginx配置中定义了一个名为timed的自定义日志格式，但默认服务器块尚未使用此格式。 接下来，打开服务器块Nginx配置文件。

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

找到我们之前修改的server配置块，并将timed日志格式名称添加到以下以红色显示的access_log设置中：

. . .
# 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;
. . .

保存并关闭文件以退出。

要启用新配置，请重新启动Nginx。

sudo systemctl restart nginx.service

现在，一切都成立了，我们来检查一下它的工作原理。

第5步 - 验证新配置

我们可以通过调用Nginx对curl一些请求来测试新配置，就像我们在第2步中所做的那样。这次我们将使用在第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

您将注意到，每个后续命令将需要更长的时间来执行，因为文件变大，传输它们需要更多的时间。

我们在执行这些请求后显示访问日志。

sudo tail /var/log/nginx/default-access.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

您将看到每次路径不同，显示正确的文件名，请求大小每次都会增加。 最重要的部分是最后一个突出显示的数字，这是我们刚刚以自定义日志格式配置的请求处理时间（以毫秒为单位）。 正如你所料，文件越大，转移所需的时间就越长。

如果是这样，您已经在Nginx中配置了自定义日志格式！

结论

虽然看到更大的文件需要更长的时间来传输并不是特别有用，但是当Nginx用于提供动态网站时，请求处理时间可能非常有用。 它可以用于跟踪网站中的瓶颈，并轻松找到比他们需要的时间更长的请求。

$request_time只是可以在自定义日志记录配置中使用的许多系统变量Nginx公开之一。 其他包括例如响应头发送的响应标头的值与客户端的响应。 将其他变量添加到日志格式与将它们放在日志格式字符串中一样简单，就像我们使用$request_time 。 这是一个功能强大的工具，可以为您的网站配置日志记录时利用它。

Nginx日志模块文档中描述了可用于Nginx日志格式的变量列表。