How to collect Nginx metrics (Article 2)

How to collect Nginx metrics (Article 2)
How to obtain the required NGINX metrics

How to obtain the required metrics depends on the NGINX version you are using and What metrics you want to see. (See how to monitor NGINX (Article 1) to learn more about NGINX metrics .) Both the free and open-source NGINX and the commercial version of NGINX Plus have a status module that can report metric metrics. NGINX can also configure and output Specific metrics in its logs:

Indicator availability

Metrics	NGINX (Open Source)	NGINX Plus	NGINX log
Accepts (accepted)/accepted (accepted)	X	X
Handled (processed)	X	X
Dropped (discarded)	X	X
Active)	X	X
Requests (number of requests)/total (number of all requests)	X	X
4xx code		X	X
5xx code		X	X
Request time (request processing time)			X

 

Indicator collection: NGINX (Open Source Edition)

Open-source NGINX displays several basic metrics related to the server status on a simple status page, which are provided by the HTTP stub status module you enabled. To check whether the module is enabled, run the following command:

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

If you see that the terminal outputs httpStubStatus_module, indicating that the status module is enabled.

If this command is not output, you need to enable this status module. You can use--with-http_stub_status_moduleConfiguration parameters:

1. ./configure \
2. … \
3. --with-http_stub_status_module
4. make
5. sudo make install

After verifying that this module has been enabled or you have enabled it, you also need to modify the NGINX configuration file to set a local accessible URL (for example:/nginx_status) for the status page ):

1. server {
2. location /nginx_status {
3. stub_status on;
4. access_log off;
5. allow 127.0.0.1;
6. deny all;
7. }
8. }

Note: server blocks in nginx configuration are not usually placed in the main configuration file (for example,/etc/nginx. conf), but in the auxiliary configuration file that will be loaded by the main configuration. To find the main configuration file, run the following command:

1. nginx -t

Open the listed master configuration file and search for rows starting with include near the end of the http block, for example:

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

In one of the contained configuration files, you should find the main server block. You can configure the NGINX metric output as shown above. After changing any configuration, run the following command to reload the configuration file:

1. nginx -s reload

Now you can view your metrics on the status page:

1. Active connections:24
2. server accepts handled requests
3. 115695811569584491319
4. Reading:0Writing:18Waiting:6

Note: If you want to access the status page from a remote computer, you need to add the IP address of the remote computer to the whitelist of your status configuration file, the whitelist in the preceding configuration file is only 127.0.0.1.

The NGINX status page is a simple way to quickly view the metrics. However, during continuous monitoring, You need to automatically record the data at standard intervals. The monitoring toolbox Nagios or Datadog, And the collection statistics service collectD can parse the NGINX status information.

 

Indicator collection: NGINX Plus

For business, NGINX Plus uses its ngxHttpStatus_module provides more metrics than the open-source NGINX. NGINX Plus provides these additional metrics in byte stream mode, providing information about upstream systems and high-speed cache. NGINX Plus also reports the count of all HTTP status code types (1XX, 2XX, 3XX, 4XX, 5XX. An NGINX Plus status report example can be viewed here:

NGINX Plus status board

Note: the definition of the "Active" connection in the status Dashboard of NGINX Plus and the open-source NGINX through stubStatusThe "Active" connection indicators collected by the module are slightly different. In the NGINX Plus indicator, "Active" connections do not include connections in the Waiting status (that is, "Idle" connections ).

NGINX Plus can also Output metrics in JSON format, which can be used to integrate to other monitoring systems. In NGINX Plus, you can see the metrics and health status of the given upstream server group, or simply get the response code count from a single server of the upstream Server:

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

To start the NGINX Plus indicator dashboard, you can add the status server block in the http block of the NGINX configuration file. (See the instructions on how to find related configuration files to collect open-source NGINX metrics in the previous section .) For example, to set a status dashboard (http://your.ip.address: 8080/status.html) and a JSON interface (http://your.ip.address: 8080/status), you can add the following server blocks to set:

1. server {
2. listen 8080;
3. root /usr/share/nginx/html;
4. location /status {
5. status;
6. }
7. location =/status.html {
8. }
9. }

After you reload the NGINX configuration, the status page can be used:

1. nginx -s reload

For more information about how to configure the scaling status module, see the official NGINX Plus document.

 

Indicator collection: NGINX logs

The NGINX Log Module will write custom access logs to the specified location you configured. You can customize the log format and data contained by adding or removing variables. To store detailed logs, add the following line in the server block of your configuration file (see the previous section, description of how to find related configuration files to collect NGINX indicators of the open-source version .) :

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

After changing the NGINX configuration file, run the following command to reload the configuration file:

1. nginx -s reload

The default "combined" log format includes a series of key data, such as the actual HTTP request and the corresponding response code. In the following sample log, NGINX records the 200 (successful) status code for the request/index.html and the 404 (not found) Error for accessing the nonexistent request file/fail.

1. 127.0.0.1--[19/Feb/2015:12:10:46-0500]"GET /index.html HTTP/1.1"200612"-""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"
2. 127.0.0.1--[19/Feb/2015:12:11:05-0500]"GET /fail HTTP/1.1"404570"-""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 add a new log format to the http block in the NGINX configuration file to record the request processing time:

1. log_format nginx '$remote_addr - $remote_user [$time_local] '
2. '"$request" $status $body_bytes_sent $request_time '
3. '"$http_referer" "$http_user_agent"';

Modify the access_log line of the server block in the configuration file:

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

After the configuration file is reloaded (runnginx -s reload), Your access log will include the response time, as shown below. The Unit is seconds and the precision is milliseconds. In this example, when the server receives a request for/bigbench, it returns the 33973115 (successful) status code after sending 206 bytes. The request processing time is 0.202 seconds (202 milliseconds ):

1. 127.0.0.1--[19/Feb/2015:15:50:36-0500]"GET /big.pdf HTTP/1.1"206339731150.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 various tools and services to parse and analyze NGINX logs. For example, rsyslog can monitor your logs and pass them to multiple Log Analysis Services. You can also use open-source tools such as logstash to collect and analyze logs; alternatively, you can use a unified logging layer, such as Fluentd, to collect and parse your NGINX logs.

 

Conclusion

Which of the following metrics for NGINX monitoring depends on the tools you can use and whether the information provided by these metrics meets your needs. For example, is it important to collect error rates that you need to purchase NGINX Plus or set up a system that can capture and analyze logs?

In Datadog, we have integrated NGINX and NGINX Plus, so that you can collect and monitor metrics of all Web servers with minimal settings. This article describes how to use NGINX Datadog for monitoring and start a free trial of Datadog.

For more Nginx tutorials, see the following:

Deployment of Nginx + MySQL + PHP in CentOS 6.2

Build a WEB server using Nginx

Build a Web server based on Linux6.3 + Nginx1.2 + PHP5 + MySQL5.5

Performance Tuning for Nginx in CentOS 6.3

Configure Nginx to load the ngx_pagespeed module in CentOS 6.3

Install and configure Nginx + Pcre + php-fpm in CentOS 6.4

Nginx installation and configuration instructions

Nginx log filtering using ngx_log_if does not record specific logs

Nginx details: click here
Nginx: click here

Via: https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/

Author: K Young Translator: strugglingyouth Proofreader: wxy

This article was originally translated by LCTT and launched with the Linux honor in China

This article permanently updates the link address: