如何将日志模块添加到Nginx的在Ubuntu 16.04

介绍

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

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

在本指南中，我们将讨论如何利用Nginx的日志模块。 我们将为不同的服务器块设置单独的日志文件，然后自定义日志记录输出。 我们还将添加有关请求的附加信息（在本教程的示例中，提供请求所需的时间）到访问日志，超出了Nginx默认包括的内容。

先决条件

要遵循本教程，您需要：

• 一个Ubuntu的16.04服务器设置与初始服务器设置教程 ，包括Sudo非root用户。

• 遵循您的服务器上安装的Nginx 如何在Ubuntu 16.04安装教程Nginx的 。

第1步 - 创建测试文件

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

当Nginx（或任何其他Web服务器）接收到对文件的HTTP请求时，它打开该文件，并通过网络传输其内容将其提供给用户。 文件越小，可以传输的速度越快。 当文件完全传输时，请求被认为完成，并且只有传输被记录。

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

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

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响应每个请求。

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

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

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

HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Thu, 30 Jun 2016 18:10:15 GMT
Content-Type: application/octet-stream
Content-Length: 0
Last-Modified: Thu, 30 Jun 2016 18:10:07 GMT
Connection: keep-alive
ETag: "5775607f-0"
Accept-Ranges: bytes

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

• HTTP/1.1 200 OK告诉我们，Nginx的回应200 OK状态码告诉我们没有错误。
• Content-Length: 0表示返回的文档的长度为零。
• 该请求在处理Thu, 30 Jun 2016 18:10:15 GMT 。

让我们看看这是否匹配Nginx存储在它的访问日志中。 日志文件只能由管理用户可读的，所以sudo必须用来访问它们。

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

日志将包含这样的行，对应于我们先前发出的测试请求。

127.0.0.1 - - [30/Jun/2016:14:10:15 -0400] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.47.0"

Nginx的使用组合日志格式 ，它是互操作性常用的Web服务器访问日志的标准格式。 在此格式中，每条信息由单个空格分隔; 连字符表示缺少的信息。

从左到右，类别是：

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

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

• 根据HTTP基本验证登录用户的用户名 。 对于所有匿名请求，此字段为空。

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

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

• 响应状态代码 ，这是200 OK ，这意味着成功。

• 所传送的文件的长度 ，这是0这里，因为该文件是空的。

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

  HTTP Referer头是“referrer”一词的拼写错误，它返回HTTP的起源，是HTTP标准的一部分。

• 用户代理 ，它是curl这里。

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

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

接下来，我们将覆盖默认日志配置（其中Nginx为所有请求存储一个访问日志文件），并使Nginx为清洁Nginx安装附带的默认服务器块存储单独的日志文件。 您可以使用Nginx的服务器模块通过读取结识如何在Ubuntu 16.04设置的Nginx服务器块（虚拟主机）的教程。

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

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

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

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

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

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

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

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

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

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

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

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

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的配置定义赋时自定义日志格式，但默认服务器块不使用此格式呢。 接下来，打开服务器块的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

现在，一切设置，让我们检查它的工作。

第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 - - [04/Jul/2016:14:57:02 -0400] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.47.0" 0.000
127.0.0.1 - - [04/Jul/2016:14:57:51 -0400] "GET /1mb.test HTTP/1.1" 200 1048576 "-" "curl/7.47.0" 0.000
127.0.0.1 - - [04/Jul/2016:14:57:57 -0400] "GET /10mb.test HTTP/1.1" 200 10485760 "-" "curl/7.47.0" 1.901
127.0.0.1 - - [04/Jul/2016:14:58:52 -0400] "GET /100mb.test HTTP/1.1" 200 104857600 "-" "curl/7.47.0" 49.232

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

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

结论

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

$request_time只是众多系统变量中的一个Nginx的公开，可以在自定义日志记录配置中使用。 其他包括例如与响应向客户端发送的响应报头的值。 添加其他变量的日志格式将它们放在就像我们做的日志格式串一样简单$request_time 。 它是一个强大的工具，您可以使用您的优势，同时配置您的网站的日志记录。

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