nginx 日志和监控

原文地址：http://nginx.com/resources/admin-guide/logging-and-monitoring/

交流地址：http://lingang.me/blog/view?id=29

Logging and Monitoring
日志和监控

This section describes how to configure logging of errors and processed requests, as well as how to use the runtime monitoring service of NGINX and NGINX Plus.

本文学习，如何配置错误日志与处理请求，以及如何使用NGINX和NGINX+的实时监控服务。

In This Section  本章有

• Setting up the error log    搭建错误日志
• Setting up the access log    搭建访问日志
• Logging to syslog      记录到系统日志
• Live activity monitoring     实时活动监控

Setting Up the Error Log
搭建错误日志

NGINX writes information about encountered issues of different severity levels to the error log. The error_log directive sets up logging to a partifular file, stderr, or syslog and specifies the minimal severity level of messages to log. By default, the error log is located at logs/error.log (the absolute path depends on the operating system and installation), and messages from all severity levels above the one specified are logged.

Nginx把遇到的不同级别的问题信息写到错误日志。error_log 指令配置记录到特定的文件，stderr，或者syslog，配置写到日志的最低级别信息。默认地，错误日志位于logs/error.log(绝对路径取决于操作系统和安装方式），比指定级别更高级别的信息都将被记录。

The configuration below changes the minimal severity level of error messages to log from error to warn.

下面这个配置把记录到日志的错误信息的最低级别由 error 改为 warn。

error_log logs/error.log warn;

In this case messages of warn, error, crit, alert, and emerg levels will be logged.

这样warn, error, crit, alert, emger 级别的信息都会被记录。

The default setting of the error log works globally. To override it, the error_log directive should be placed in the main context. The settings of the main context are always inherited by other levels. The error_log directive can be specified on other levels too, cancelling the effect inherited from the higher levels. In case of an error, the message will be written to only one error log. This log will be the closest to the level where the error has occurred. However, if several error_log directives are specified on the same level, the message will be written to to all logs specified.

默认的错误日志设置是全局的。要覆盖它，error_log 指令必须放在main环境中。man环境里的设置都会被其他层继承。error_log指令也可以在其他层里指定，以取消从更高层继承下来的。如果发生一个错误，信息只会被写到一个错误日志。这个日志将写到错误发生的最近的那一层。然而，如果在同一个层定义了多个error_log指令，信息会被写到所有指定的日志文件。

Note: Using several error log directives at the same level are supported in NGINX versions 1.5.2 and greater.

注意：同一层使用多个错误日志需要Nginx版本为1.5.2或更高。

Setting Up the Access Log
设置访问日志

To the access a log, NGINX writes information about client requests after the request is processed. By default, the access log is located at logs/access.log, and the information is written to the log in the predefined, combined format. To override the default setting, use the log_format directive to configure a format of logged messages, as well as the access_log directive to specify the location of the log and the format. The format is defined using variables.

Nginx处理请求后把关于客户端请求的信息写到访问日志。默认，访问日志位于 logs/access.log，写到日志的信息是预定义的、组合的格式。要覆盖默认的配置，使用log_format指令来配置一个记录信息的格式，同样使用access_log 指令到设置日志和格式和位置。格式定义使用变量。

The following examples define a format that extends the standard combined format with the value indicating the ratio of gzip compression of the response. The format is then applied to a virtual server that enables compression.

下面这个例子定义一个格式，这个格式在标准组合格式上进行扩展加入对响应进行gzip压缩的比率的值。该格式被应用于一个开启了压缩的虚拟服务器。

http {
    log_format compression '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" "$gzip_ratio"';

    server {
        gzip on;
        access_log /spool/logs/nginx-access.log compression;
        ...
    }
}

Logging can be optimized by enabling the buffer for log messages and the cache of descriptors of frequently used log files whose names contain variables. To enable buffering use the buffer parameter of the access_log directive to specify the size of the buffer. The buffered messages are then written to the log file when the next log message does not fit into the buffer as well as in some other cases. To enable caching of log file descriptors, use the open_log_file_cache directive.

开启日志信息缓冲，被频繁使用且名字包含变量的文件的操作的缓存，能够优化日志记录。要开始缓冲，使用access_log指令的buffer参数来指定缓冲的大小。缓冲区里的信息在缓冲区不够写下一个信息时以及另外的一些情况下写入日志文件。要开启文件操作的缓存，使用open_log_file_cache指令。

Similar to the error_log directive, the access_log directive defined on a level overrides the settings from the previous levels. When processing of a request is completed, the message is written to the log that is configured on the current level, or inherited from the previous levels. If one level defines multiple access logs, the message is written to all of them.

与error_log指令相似， 定义了access_log指令的层将会把从上一层继承下来的设置覆盖。当一个请求的处理完毕，信息被写到由当前层定义或者从上层继承下来的日志文件中。如果一个层里定义了多个访问日志，信息会被写到所有日志中。

Enabling Conditional Logging
开启有条件的日志记录

Conditional logging allows excluding trivial or non-important log entries from the access log. In NGINX, conditional logging is enabled by the if parameter of the access_log directive.

根据条件的日志记录能不记录细枝末节和不重要的日志条目到访问日志中。在Nginx中，条件性日志记录使用access_log指令的 if 参数开启。

For example, it makes possible to exclude requests with HTTP status codes 2XX (Success) and 3XX (Redirection):

例如，可以把状态码以2和3开头的HTTP请求忽略不计：

map $status $loggable {
    ~^[23]  0;
    default 1;
}
access_log /path/to/access.log combined if=$loggable;

Logging to Syslog
记录到系统日志

Syslog is a standard for computer message logging and allows collecting log messages from different devices on a single syslog server. In NGINX, logging to syslog is configured with the syslog: prefix in error_log and access_log directives.

系统日志是一个计算机信息记录标准，能够记录来自不同设备的日志信息到一个单一的系统日志服务器。在Nginx中，记录到系统日志要在error_log 和 access_log指令中加前缀 syslog: 来配置。

Syslog messages can be sent to a server= which can be a domain name, an IP address, or a UNIX-domain socket path. A domain name or IP address can be specified with a port, by default port 514 is used. A UNIX-domain socket path can be specified after the unix: prefix:

系统日志信息能被发送到一个server=，server=后面可以是一个域名，一个IP地址或者一个unix-domain套接字路径。域名或者ip地址能指定端口，默认端口为514，unix-domain套接字路径跟在前缀unix:后：

error_log server=unix:/var/log/nginx.sock debug;
access_log syslog:server=[2001:db8::1]:1234,facility=local7,tag=nginx,severity=info;

In the example, NGINX error log messages will be written to UNIX domain socket with the debug logging level, and the access log will be written to a syslog server with IPv6 address and port 1234.

本例中，Nginx错误日志消息以debug日志级别记录到 UNIX 域套接字，访问日志将被记录到一个IPv6地址商品为1234的系统日志服务器。

The facility= parameter specifies the type of program which is logging the message. The default value is local7. Other values may be: auth, authpriv, daemon, cron, ftp, lpr, kern, mail,news, syslog, user, uucp, local0 … local7.

参数facility=指定记录日志消息的程序类型。缺省值为local7，其他可用值有: auth, authpriv, daemon, cron, ftp, lpr, kern, mail,news, syslog, user, uucp, local0 … local7.

The tag= parameter will apply a custom tag to syslog messages, in our example the tag is nginx.

参数tag=在系统日志消息中应用一个自定义标签，上例中标签为nginx。

The severity= parameter sets the severity level of syslog messages for access log. Possible values in order of increasing severity are: debug, info, notice, warn, error (default), crit, alert, and emerg. In our example, the severity level error will also enable crit, alert, and emerg levels to be logged.

参数severity=设置访问日志的系统日志消息的严重级别。可使用的值按严重级别顺序递增为：debug, info, notice, warn, error (default), crit, alert, and emerg。我们的例子中，严重级别error将开启crit, alert, emerg 级别的记录。

Live Activity Monitoring
实时活动监控

NGINX Plus provides a real-time activity monitoring interface that shows key load and performance metrics of your upstream servers as well as other data including:

Nginx + 提供一个实时活动监控界面，展示键的负载和上游服务器的性能指标，以及其他数据包括：

• NIGNX basic version, uptime and identification information;
• Nginx基础版本，运行时间和认证信息；
• total and current numbers of connections and requests;
• 连接和请求的当前数目以及总数目；
• request and response counts for each status_zone;
• 每个status_zone的请求和响应数；
• request and response counts per server in each dynamically configured groups of servers, plus health-check and uptime statistics;
• 每个服务器动态配置组的请求和响应数，还有健康检测和正常运行时间统计；
• statistics per server, including its current state and total values (total fails etc.)
• 统计每个服务器，包含当前状态和总体值（总体失败次数等）。
• instrumentation for each named cache zone.
• 每个命名过的缓存空间的检测表。

The complete list of metrics is available here.

性能指标的完整列表点击此处。

The statistics can be viewed from the status.html page already included in each NGINX Plus package. The page polls status information and displays it in a simple table:

统计数据可以从status.html页面查看，该页面已包含在每个Nginx+的包里。页面统计状态信息并且展示在一个简单的表里：http://demo.nginx.com/status.html

And using a simple RESTful JSON interface, it’s easy to connect these stats to live dashboards and third-party monitoring tools.

还可以使用一个简单的 RESTful JSON 接口，可以通过第三方监控平台轻松连接这些状态做一个实时仪表盘。

Enabling Activity Monitoring
开启活动监控

To enable real-time activity monitoring and the JSON interface, you must specify the location that checks the exact match of the URI with /status and contains the status directive. To enable the status.html page, you must specify one more location that sets it:

要开启实时活动监控和 JSON 接口，必须在精确匹配 /status 的 location 里包含 status 指令。要启用status.html页面，你必须在至少一个location里设置它：

server {
    listen 127.0.0.1;
    root /usr/share/nginx/html;

    location /status {
        status;
    }

    location = /status.html {
    }
}

With the following configuration, the webpage  status.html located at  /usr/share/nginx/html can be requested by the URL  http://127.0.0.1/status.html.

根据这个配置，网页status.html位于/usr/share/nginx/html能通过URL http://127.0.0.1/status.html 访问到。

Using RESTful JSON Interface
使用 RESTful JSON 接口

NGINX Plus stats can be easlily connected to third-party applications, such as performance dashboards. This can be done with the JSON interface.

Nginx+的统计能轻松连接到第三方应用，比如性能仪表盘。可以通过JSON接口实现。

If you request /status (or whichever URI matches the location group), then NGINX Plus will respond with a JSON document containing the current activity data.

如果你请求/status（或者任何一个能匹配这个location 组的URI），Nginx+将响应一个包含当前活动数据的JSON文档。

The status information of any element in the JSON document can be requested by a slash-separated URL:

JSON文档的每一个元素的状态信息都可以通过在请求后用斜线分隔的URL来请求：

http://127.0.0.1/status
http://127.0.0.1/status/nginx_version
http://127.0.0.1/status/caches/cache_backend
http://127.0.0.1/status/upstreams
http://127.0.0.1/status/upstreams/backend
http://127.0.0.1/status/upstreams/backend/1
http://127.0.0.1/status/upstreams/backend/1/weight

To learn more about NGINX Plus, please see the descriptions of our commercial subscriptions.

更多关于NGINX+的信息，主参阅我们的商业订阅。