如何收集 NGINX 指标（第二篇）
NGINX
![](/data/attachment/album/201508/10/143028a5uwtvjnbag86zv5.png)


### 如何获取你所需要的 NGINX 指标


如何获取需要的指标取决于你正在使用的 NGINX 版本以及你希望看到哪些指标。（参见 [如何监控 NGINX（第一篇）](https://www.datadoghq.com/blog/how-to-monitor-nginx/) 来深入了解NGINX指标。）自由开源的 NGINX 和商业版的 NGINX Plus 都有可以报告指标度量的状态模块，NGINX 也可以在其日志中配置输出特定指标：


**指标可用性**




| 指标 | [NGINX (开源)](https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/#open-source) | [NGINX Plus](https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/#plus) | [NGINX 日志](https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/#logs) |
| --- | --- | --- | --- |
| accepts（接受） / accepted（已接受） | x | x |  |
| handled（已处理） | x | x |  |
| dropped（已丢弃） | x | x |  |
| active（活跃） | x | x |  |
| requests （请求数）/ total（全部请求数） | x | x |  |
| 4xx 代码 |  | x | x |
| 5xx 代码 |  | x | x |
| request time（请求处理时间） |  |  | x |


#### 指标收集：NGINX（开源版）


开源版的 NGINX 会在一个简单的状态页面上显示几个与服务器状态有关的基本指标，它们由你启用的 HTTP [stub status module](http://nginx.org/en/docs/http/ngx_http_stub_status_module.html) 所提供。要检查该模块是否已启用，运行以下命令：



```
nginx -V 2>&1 | grep -o with-http_stub_status_module 

```

如果你看到终端输出了 **http*stub*status\_module**，说明该状态模块已启用。


如果该命令没有输出，你需要启用该状态模块。你可以在[从源代码构建 NGINX](http://wiki.nginx.org/InstallOptions) 时使用 `--with-http_stub_status_module` 配置参数:



```
./configure \
… \
--with-http_stub_status_module
make
sudo make install

```

在验证该模块已经启用或你自己启用它后，你还需要修改 NGINX 配置文件，来给状态页面设置一个本地可访问的 URL（例如： /nginx\_status）：



```
server {
    location /nginx_status {
        stub_status on;

        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

```

注：nginx 配置中的 server 块通常并不放在主配置文件中（例如：/etc/nginx/nginx.conf），而是放在主配置会加载的辅助配置文件中。要找到主配置文件，首先运行以下命令：



```
nginx -t 

```

打开列出的主配置文件，在以 http 块结尾的附近查找以 include 开头的行，如：



```
include /etc/nginx/conf.d/*.conf; 

```

在其中一个包含的配置文件中，你应该会找到主 **server** 块，你可以如上所示配置 NGINX 的指标输出。更改任何配置后，通过执行以下命令重新加载配置文件：



```
nginx -s reload 

```

现在，你可以浏览状态页看到你的指标：



```
Active connections: 24 
server accepts handled requests
1156958 1156958 4491319
Reading: 0 Writing: 18 Waiting : 6 

```

请注意，如果你希望从远程计算机访问该状态页面，则需要将远程计算机的 IP 地址添加到你的状态配置文件的白名单中，在上面的配置文件中的白名单仅有 127.0.0.1。


NGINX 的状态页面是一种快速查看指标状况的简单方法，但当连续监测时，你需要按照标准间隔自动记录该数据。监控工具箱 [Nagios](https://exchange.nagios.org/directory/Plugins/Web-Servers/nginx) 或者 [Datadog](http://docs.datadoghq.com/integrations/nginx/)，以及收集统计信息的服务 [collectD](https://collectd.org/wiki/index.php/Plugin:nginx) 已经可以解析 NGINX 的状态信息了。


#### 指标收集: NGINX Plus


商业版的 NGINX Plus 通过它的 ngx*http*status\_module 提供了比开源版 NGINX [更多的指标](http://nginx.org/en/docs/http/ngx_http_status_module.html#data)。NGINX Plus 以字节流的方式提供这些额外的指标，提供了关于上游系统和高速缓存的信息。NGINX Plus 也会报告所有的 HTTP 状态码类型（1XX，2XX，3XX，4XX，5XX）的计数。一个 NGINX Plus 状态报告例子[可在此查看](http://demo.nginx.com/status.html)：


![NGINX Plus status board](/data/attachment/album/201508/10/143138qrti1hj61w57htit.png)


注：NGINX Plus 在状态仪表盘中的“Active”连接的定义和开源 NGINX 通过 stub*status*module 收集的“Active”连接指标略有不同。在 NGINX Plus 指标中，“Active”连接不包括Waiting状态的连接（即“Idle”连接）。


NGINX Plus 也可以输出 [JSON 格式的指标](http://demo.nginx.com/status)，可以用于集成到其他监控系统。在 NGINX Plus 中，你可以看到 [给定的上游服务器组](http://demo.nginx.com/status/upstreams/demoupstreams)的指标和健康状况，或者简单地从上游服务器的[单个服务器](http://demo.nginx.com/status/upstreams/demoupstreams/0/responses)得到响应代码的计数：



```
{"1xx":0,"2xx":3483032,"3xx":0,"4xx":23,"5xx":0,"total":3483055}

```

要启动 NGINX Plus 指标仪表盘，你可以在 NGINX 配置文件的 http 块内添加状态 server 块。 (参见上一节，为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。）例如，要设置一个状态仪表盘 （[http://your.ip.address:8080/status.html）和一个](http://your.ip.address:8080/status.html%EF%BC%89%E5%92%8C%E4%B8%80%E4%B8%AA) JSON 接口（[http://your.ip.address:8080/status），可以添加以下](http://your.ip.address:8080/status%EF%BC%89%EF%BC%8C%E5%8F%AF%E4%BB%A5%E6%B7%BB%E5%8A%A0%E4%BB%A5%E4%B8%8B) server 块来设定：



```
server {
    listen 8080;
    root /usr/share/nginx/html;

    location /status {
        status;
    }

    location = /status.html {
    }
}

```

当你重新加载 NGINX 配置后，状态页就可以用了：



```
nginx -s reload 

```

关于如何配置扩展状态模块，官方 NGINX Plus 文档有 [详细介绍](http://nginx.org/en/docs/http/ngx_http_status_module.html#example) 。


#### 指标收集：NGINX 日志


NGINX 的 [日志模块](http://nginx.org/en/docs/http/ngx_http_log_module.html) 会把可自定义的访问日志写到你配置的指定位置。你可以通过[添加或移除变量](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format)来自定义日志的格式和包含的数据。要存储详细的日志，最简单的方法是添加下面一行在你配置文件的 server 块中（参见上上节，为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。）：



```
access_log logs/host.access.log combined;

```

更改 NGINX 配置文件后，执行如下命令重新加载配置文件：



```
nginx -s reload

```

默认包含的 “combined” 的日志格式，会包括[一系列关键的数据](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format)，如实际的 HTTP 请求和相应的响应代码。在下面的示例日志中，NGINX 记录了请求 /index.html 时的 200（成功）状态码和访问不存在的请求文件 /fail 的 404（未找到）错误。



```
127.0.0.1 - - [19/Feb/2015:12:10:46 -0500] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari 537.36"

127.0.0.1 - - [19/Feb/2015:12:11:05 -0500] "GET /fail HTTP/1.1" 404 570 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

```

你可以通过在 NGINX 配置文件中的 http 块添加一个新的日志格式来记录请求处理时间：



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

```

并修改配置文件中 **server** 块的 access\_log 行：



```
access_log logs/host.access.log nginx;

```

重新加载配置文件后（运行 `nginx -s reload`），你的访问日志将包括响应时间，如下所示。单位为秒，精度到毫秒。在这个例子中，服务器接收到一个对 /big.pdf 的请求时，发送 33973115 字节后返回 206（成功）状态码。处理请求用时 0.202 秒（202毫秒）：



```
127.0.0.1 - - [19/Feb/2015:15:50:36 -0500] "GET /big.pdf HTTP/1.1" 206 33973115 0.202 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

```

你可以使用各种工具和服务来解析和分析 NGINX 日志。例如，[rsyslog](http://www.rsyslog.com/) 可以监视你的日志，并将其传递给多个日志分析服务；你也可以使用自由开源工具，比如 [logstash](https://www.elastic.co/products/logstash) 来收集和分析日志；或者你可以使用一个统一日志记录层，如 [Fluentd](http://www.fluentd.org/) 来收集和解析你的 NGINX 日志。


### 结论


监视 NGINX 的哪一项指标将取决于你可用的工具，以及监控指标所提供的信息是否满足你们的需要。举例来说，错误率的收集是否足够重要到需要你们购买 NGINX Plus ，还是架设一个可以捕获和分析日志的系统就够了？


在 Datadog 中，我们已经集成了 NGINX 和 NGINX Plus，这样你就可以以最小的设置来收集和监控所有 Web 服务器的指标。[在本文中](https://www.datadoghq.com/blog/how-to-monitor-nginx-with-datadog/)了解如何用 NGINX Datadog 来监控 ，并开始 [Datadog 的免费试用](https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/#sign-up)吧。




---


via: <https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/>


作者：K Young 译者：[strugglingyouth](https://github.com/strugglingyouth) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出


OK
[How to get the NGINX metrics you need](#how-to-get-the-nginx-metrics-you-need)

How you go about capturing metrics depends on which version of NGINX you are using, as well as which metrics you wish to access. (See [the companion article](https://www.datadoghq.com/blog/how-to-monitor-nginx/) for an in-depth exploration of NGINX metrics.) Free, open source NGINX and the commercial product NGINX Plus both have status modules that report metrics, and NGINX can also be configured to report certain metrics in its logs:

Metric | Availability | ||
---|---|---|---|

|


[NGINX Plus](#metrics-collection-nginx-plus)

[NGINX logs](#metrics-collection-nginx-logs)

[Metrics collection: NGINX (open source)](#metrics-collection-nginx-open-source)

Open source NGINX exposes several basic metrics about server activity on a simple status page, provided that you have the HTTP [stub status module](http://nginx.org/en/docs/http/ngx_http_stub_status_module.html) enabled. To check if the module is already enabled, run:

```
nginx -V 2>&1 | grep -o with-http_stub_status_module
```


The status module is enabled if you see `with-http_stub_status_module`

as output in the terminal.

If that command returns no output, you will need to enable the status module. You can use the `--with-http_stub_status_module`

configuration parameter when [building NGINX from source](https://www.nginx.com/resources/wiki/start/topics/tutorials/installoptions/):

```
./configure \
… \
--with-http_stub_status_module
make
sudo make install
```


After verifying the module is enabled or enabling it yourself, you will also need to modify your NGINX configuration to set up a locally accessible URL (e.g., `/nginx_status`

) for the status page:

```
server {
location /nginx_status {
stub_status;
access_log off;
allow 127.0.0.1;
deny all;
}
}
```


Note: The `server`

blocks of the NGINX config are usually found not in the main configuration file (e.g., `/etc/nginx/nginx.conf`

) but in supplemental configuration files that are referenced by the main config. To find the relevant configuration files, first locate the main config by running:

```
nginx -t
```


Open the configuration file listed, and look for lines beginning with `include`

near the end of the `http`

block, such as:

```
include /etc/nginx/conf.d/*.conf;
```


In one of the referenced config files you should find the main `server`

block, which you can modify as above to configure NGINX metrics reporting. After changing any configurations, reload the configs by executing:

```
nginx -s reload
```


Now you can view the status page to see your metrics:

```
Active connections: 24
server accepts handled requests
1156958 1156958 4491319
Reading: 0 Writing: 18 Waiting : 6
```


Note that if you are trying to access the status page from a remote machine, you will need to edit your status configuration to allow the remote machine’s IP address, just as 127.0.0.1 is allowed in the configuration snippet above.

The NGINX status page is an easy way to get a quick snapshot of your metrics, but for continuous monitoring you will need to automatically record that data at regular intervals. Parsers for the NGINX status page already exist for monitoring tools such as [Nagios](https://exchange.nagios.org/directory/Plugins/Web-Servers/nginx) and [Datadog](https://docs.datadoghq.com/integrations/nginx/), as well as for the statistics collection daemon [collectD](https://collectd.org/wiki/index.php/Plugin:nginx).

[Metrics collection: NGINX Plus](#metrics-collection-nginx-plus)

The commercial NGINX Plus provides [many more metrics](http://nginx.org/en/docs/http/ngx_http_api_module.html#definitions) through its ngx_http_api_module than are available in open source NGINX. Among the additional metrics exposed by NGINX Plus are bytes streamed, as well as information about upstream systems and caches. NGINX Plus also reports counts of all HTTP status code types (1xx, 2xx, 3xx, 4xx, 5xx). A sample NGINX Plus status board is available [here](http://demo.nginx.com/status.html).

*Note: the “Active” connections on the NGINX Plus status dashboard are defined slightly differently than the Active state connections in the metrics collected via the open source NGINX stub status module. In NGINX Plus metrics, Active connections do not include connections in the Waiting state (aka Idle connections).*

NGINX Plus also reports [metrics in JSON format](http://demo.nginx.com/api/3) for easier integration with external monitoring systems. With NGINX Plus, you can see the metrics and health status for a given upstream grouping of servers, or drill down to get a count of just the response codes from a single server in that upstream. Sending a request to `/http/server_zones/<SERVER_ZONE_NAME>`

, for example, will [return metrics](http://nginx.org/en/docs/http/ngx_http_api_module.html#http_server_zones_http_server_zone_name) resembling the following JSON object, which you can access in the NGINX Plus [live demo API](http://demo.nginx.com/api/3/http/server_zones):

```
{
"processing": 0,
"requests": 50818,
"responses": {
"1xx": 0,
"2xx": 46127,
"3xx": 3822,
"4xx": 825,
"5xx": 1,
"total": 50775
},
"discarded": 43,
"received": 14137130,
"sent": 1429876113
}
```


To [enable](https://www.nginx.com/blog/live-activity-monitoring-nginx-plus-3-simple-steps/) the NGINX Plus metrics dashboard, you can add a status `server`

block inside the `http`

block of your NGINX configuration. ([See the section above](#metrics-collection-nginx-open-source) on collecting metrics from open source NGINX for instructions on locating the relevant config files.) For example, to set up a status dashboard at `http://<SERVER_IP_ADDRESS>:8080/status.html`

and a JSON interface at `http://<SERVER_IP_ADDRESS>:8080/status`

, you would add the following server block:

```
server {
listen 8080;
root /usr/share/nginx/html;
location /status {
api;
}
location = /status.html {
}
}
```


You can find an annotated example of a config file for an NGINX Plus status module [here](https://gist.githubusercontent.com/nginx-gists/a51341a11ff1cf4e94ac359b67f1c4ae/raw/bf9b68cca20c87f303004913a6a9e9032f24d143/nginx-plus-api.conf). To collect metrics from an upstream server group on your dashboard, you’ll need to add a `status_zone`

[directive](http://nginx.org/en/docs/http/ngx_http_api_module.html#directives) to your `server`

block.

The status pages should be live once you reload your NGINX configuration:

```
nginx -s reload
```


The official NGINX Plus docs have [more details](http://nginx.org/en/docs/http/ngx_http_api_module.html#example) on how to configure the expanded status module.

[Metrics collection: NGINX logs](#metrics-collection-nginx-logs)

NGINX’s [log module](http://nginx.org/en/docs/http/ngx_http_log_module.html) writes configurable access logs to a destination of your choosing. You can customize the format of your logs and the data they contain by [adding or subtracting variables](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format). The simplest way to capture detailed logs is to add the following line in the `server`

block of your config file (see [the section](#metrics-collection-nginx-open-source) on collecting metrics from open source NGINX for instructions on locating your config files):

```
access_log logs/host.access.log combined;
```


After changing any NGINX configurations, reload the configs by executing:

```
nginx -s reload
```


The “combined” log format, included by default, captures [a number of key datapoints](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format), such as the actual HTTP request and the corresponding response code. In the example logs below, NGINX logged a 200 (success) status code for a request for /index.html and a 404 (not found) error for the nonexistent /fail.

```
127.0.0.1 - - [19/Feb/2015:12:10:46 -0500] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari 537.36"
127.0.0.1 - - [19/Feb/2015:12:11:05 -0500] "GET /fail HTTP/1.1" 404 570 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"
```


You can log request processing time as well by adding a new log format to the `http`

block of your NGINX config file:

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


And by adding or modifying the `access_log`

line in the `server`

block of your config file (the `nginx`

parameter names the format we defined earlier):

```
access_log logs/host.access.log nginx;
```


After reloading the updated configs (by running `nginx -s reload`

), your access logs will include response times, as seen below. The units are seconds, with millisecond resolution. In this instance, the server received a request for /big.pdf, returning a 206 (success) status code after sending 33973115 bytes. Processing the request took 0.202 seconds (202 milliseconds):

```
127.0.0.1 - - [19/Feb/2015:15:50:36 -0500] "GET /big.pdf HTTP/1.1" 206 33973115 0.202 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"
```


You can use a variety of tools and services to parse and analyze NGINX logs. For instance, [rsyslog](https://github.com/rsyslog/rsyslog) can monitor your logs and pass them to any number of log-analytics services; you can use a free, open source tool such as [logstash](https://www.elastic.co/products/logstash) to collect and analyze logs; or you can use a unified logging layer such as [Fluentd](http://www.fluentd.org/) to collect and parse your NGINX logs. You can also use Datadog to collect and analyze NGINX logs, which we’ll explore in [part 3](https://www.datadoghq.com/blog/how-to-monitor-nginx-with-datadog/) of this series.

[Conclusion](#conclusion)

Which NGINX metrics you monitor will depend on the tools available to you, and whether the insight provided by a given metric justifies the overhead of monitoring that metric. For instance, is measuring error rates important enough to your organization to justify investing in NGINX Plus or implementing a system to capture and analyze logs?

At Datadog, we have built a single integration that supports both NGINX and NGINX Plus so that you can begin collecting and monitoring metrics from all your web servers with a minimum of setup. Learn how to monitor NGINX metrics with Datadog [in this post](https://www.datadoghq.com/blog/how-to-monitor-nginx-with-datadog/), and get started right away with [a free trial of Datadog](#).

*Source Markdown for this post is available on GitHub. Questions, corrections, additions, etc.? Please let us know.*