NGINX大全 第十四章 使用访问日志，错误日志和请求跟踪进行调试和故障排除

第十四章 使用访问日志，错误日志和请求跟踪进行调试和故障排除

14.0 介绍

日志记录是了解您的应用程序的基础。使用NGINX，您可以很好地控制对您和您的应用程序有意义的日志信息。NGINX允许您将访问日志(access log)分为不同的文件和格式，以用于不同的上下文，并可以更改错误日志(error log)的日志级别，以更深入地了解正在发生的事情。NGINX通过其Syslog日志记录功能将日志流传输到集中式服务器的功能是与生俱来的。在本章中，我们将讨论访问和错误日志，通过Syslog协议进行流传输以及使用NGINX生成的请求标识符来端到端地跟踪请求。

14.1 配置访问日志

问题

您需要配置访问日志格式，以将内置变量添加到您的请求日志中。

解决方案

配置访问日志格式：

http {
    log_format geoproxy
               '[$time_local] $remote_addr '
               '$realip_remote_addr $remote_user '
               '$request_method $server_protocol '
               '$scheme $server_name $uri $status '
               '$request_time $body_bytes_sent '
               '$geoip_city_country_code3 $geoip_region '
               '"$geoip_city" $http_x_forwarded_for '
               '$upstream_status $upstream_response_time '
               '"$http_referer" "$http_user_agent"';
               ...
}

这种日志格式配置名为geoproxy，并使用许多内置变量来演示NGINX日志记录的功能。此配置显示了发出请求时服务器上的本地时间，打开连接的IP地址，以及NGINX根据geoip_proxy或realip_header指令得到的客户端IP。$remote_user显示通过基本身份验证进行身份验证的用户的用户名，其后是请求方法和协议，以及方案，例如HTTP或HTTPS。匹配的服务器名称，以及请求URI和返回状态代码，一起被记录。记录的统计信息包括处理时间（以毫秒为单位）和发送给客户端的body大小。有关国家，地区和城市的信息被记录。包含了HTTP header X-Forwarded-For，以显示请求是否由另一个代理转发。upstream模块启用了我们使用的一些内置变量，这些变量显示了从upstream服务器返回的状态以及upstream请求返回所需的时间。最后，我们记录了一些有关从何处引用客户端以及客户端使用哪种浏览器的信息。log_format指令仅在HTTP上下文中有效。

此日志配置将呈现如下所示的日志条目：

[25/Nov/2016:16:20:42 +0000] 10.0.1.16 192.168.0.122 Derek GET HTTP/1.1 http www.example.com / 200 0.001 370 USA MI "Ann Arbor" - 200 0.001 "-" "curl/7.47.0"

要使用这种日志格式，请使用access_log指令，并提供日志文件路径和格式名称geoproxy作为参数：

server {
    access_log /var/log/nginx/access.log geoproxy;
    ...
}

access_log指令将日志文件路径和格式名称作为参数。 该指令在许多上下文中均有效，并且在每个上下文中可以具有不同的日志路径和日志格式。

讨论

NGINX中的日志模块允许您为许多不同的场景配置日志格式，以便在您认为合适的情况下记录到众多日志文件中。您可能会发现为每个上下文配置不同的日志格式很有用，在这种情况下您将使用不同的模块并使用这些模块的内置变量，或者是一种单独的，可提供全部所需信息的包罗万象的格式。还可以使用JSON或XML格式化日志。这些日志将帮助您了解流量模式，客户端使用情况，客户端是谁以及客户端来自何处。访问日志还可以帮助您发现响应延迟和upstream服务器或特定URI的问题。访问日志可用于解析和回放测试环境中的流量模式，以模拟实际的用户交互。在对应用程序或市场进行故障排除，调试或分析时，记录日志的可能性是无限的。

14.2 配置错误日志

问题

您需要配置错误日志记录，以更好地了解NGINX服务器的问题。

解决方案

使用error_log指令定义日志路径和日志级别：

error_log /var/log/nginx/error.log warn;

error_log指令需要一个路径参数, 而日志级别参数是可选的。该指令在除if语句外的所有上下文中均有效。可用的日志级别为debug，info，notice，warn，error，crit，alert或emerg。引入这些日志级别的顺序也是从最低到最高的严重性顺序。只有在NGINX配置了--with-debug标志时，debug日志级别才可用。

讨论

当配置文件无法正常工作时，错误日志是第一个要查看的。该日志也是查找由FastCGI之类的应用程序服务器产生的错误的好地方。您可以使用错误日志来调试与工作服务器，内存分配，客户端IP和服务器的连接。错误日志无法格式化。但是，它遵循特定的日期格式，然后是级别，然后是消息。

14.3 转发到Syslog

问题

您需要将日志转发到Syslog侦听器，以将日志聚合到集中式服务。

解决方案

使用access_log和error_log指令将日志发送到Syslog侦听器：

error_log syslog:server=10.0.1.42 debug;
access_log syslog:server=10.0.1.42,tag=nginx,severity=info geoproxy;

用于error_log和access_log指令的syslog参数后跟一个冒号和许多选项。这些选项包括必需的服务器标志（表示要连接的IP，DNS名称或Unix套接字），以及可选标志（例如facility，severity，tag和nohostname）。服务器选项带有一个端口号，以及IP地址或DNS名称。但是，它默认为UDP 514。facility选项是指日志消息的功能，该消息定义为Syslog RFC标准中定义的23种之一。 默认值为local7。tag选项用一个值标记消息。该值默认为nginx。severity默认为info，表示所发送消息的严重性。nohostname标志禁止将主机名字段添加到Syslog消息头中，并且不使用值。

讨论

Syslog是用于发送日志消息并在单个服务器或服务器集合上收集日志的标准协议。当您在多个主机上运行同一服务的多个实例时，将日志发送到集中位置有助于进行调试。这称为汇总日志。汇总日志使您可以在一处查看日志，而不必从一台服务器跳到另一服务器，也不必根据时间戳将日志文件拼凑在一起。常见的日志聚合堆栈是ElasticSearch，Logstash和Kibana，也称为ELK堆栈。NGINX可以使用access_log和error_log指令轻松地将这些日志流式传输到Syslog侦听器。

14.4 请求追踪

问题

您需要将NGINX日志与应用程序日志相关联，以对请求进行端到端的了解。

解决方案

使用request标识变量并将其传递给您的应用程序进行日志记录：

log_format trace '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 '"$http_x_forwarded_for" $request_id';
upstream backend {
    server 10.0.0.42;
}
server {
    listen 80;
    add_header X-Request-ID $request_id; # Return to client
    location / {
        proxy_pass http://backend;
        proxy_set_header X-Request-ID $request_id; #Pass to app
        access_log /var/log/nginx/access_trace.log trace;
    }
}

在此示例配置中，设置了名为trace的log_format，在日志中使用了变量$request_id。该$request_id变量也通过使用proxy_set_header指令传递给上游应用程序，以在发出上游请求时将请求ID添加到header中。通过使用在响应header中设置请求ID的add_header指令，请求ID也被传递回客户端。

讨论

$request_id在NGINX Plus R10和NGINX 1.11.0版本中可用，提供了随机生成的32位十六进制字符的字符串，可用于唯一标识请求。通过将此标识符传递给客户端以及应用程序，您可以将日志与发出的请求相关联。从前端客户端，您将收到此唯一字符串作为响应header，并且可以使用它来在日志中搜索对应的条目。您将需要指示您的应用程序捕获此header并将其记录在其应用程序日志中，以在日志之间创建真正的端到端关系。通过这一进步，NGINX使得通过应用程序堆栈跟踪请求变得可能。