Monitoring NGINX

Monitoring NGINX

Setting up a monitoring tool for NGINX is an important part of maintaining website operations. Proper NGINX monitoring can reveal a lot of useful information about the underlying application performance. There are quite a few monitoring systems out there suitable for the task; the first step, however, is to enable metric collection in NGINX.

Using the stub_status Module

There’s a module for NGINX called ngx_http_stub_status_module (or simply stub_status) that exposes a few important metrics about NGINX activity.

To check if your NGINX build has the stub_status module, use nginx -V:

nginx -V 2>&1 | grep --color -- --with-http_stub_status_module

Our NGINX builds already include the stub_status module. Check this page for the available Linux packages.

Otherwise, you have to rebuild nginx from source, adding the parameter --with-http_stub_status_module to the configure script.

As the next step, enable the stub_status module in your NGINX configuration. You can always add a corresponding location to the existing server configuration. Alternatively, add a separate server section, with a single specialized location for use with stub_status.

server {
    listen 127.0.0.1:80;
    server_name 127.0.0.1;

    location /nginx_status {
        stub_status;
    }
}

The server blocks are sometimes found outside of the main configuration file. If you don’t see a suitable part in nginx.conf, search for the additional configuration files that are typically included in nginx.conf. You can also read more about NGINX access control lists here.

After the stub_status module is configured, don’t forget to reload the NGINX configuration (e.g., with service nginx reload). You can read more about NGINX control signals here.

To check the stub_status metrics, make a query with curl:

$ curl http://127.0.0.1/nginx_status
Active connections: 2
server accepts handled requests
841845 841845 1631067
Reading: 0 Writing: 1 Waiting: 1

If this doesn’t work, make sure to check where the requests to /nginx_status are routed. In many cases, another server block can be the reason why you can’t access the stub_status metrics. Please refer to the documentation to read more about these instance-wide NGINX metrics.

With stub_status enabled in NGINX and working, you can proceed with the installation and configuration of the monitoring system of choice.

Log files and syslog

The access log and error log in NGINX contain a lot of useful information suitable for metric collection. The access log format can be fully customized using variables in NGINX. Certain monitoring tools can leverage NGINX log files for metric collection.

To meet various performance and security requirements, you may consider using the syslog capability in NGINX. While log files are written to disk, syslog allows to send the log data over a network protocol. For example, you can set up a dedicated Linux system to collect all of your log data from various NGINX instances.

For more information on logging, please refer to the NGINX admin guide.

Monitoring NGINX with Amplify

We have a native tool for NGINX monitoring. It’s called NGINX Amplify, and it’s a SaaS tool that you can use for free with up to 5 servers.

It’s easy to start monitoring NGINX with Amplify. You can get out-of-the-box graphs for all key NGINX metrics in under 10 minutes. Amplify can automatically use metrics from stub_status and from access logs, and collect various OS information as well.

Using Amplify, you can visualize your NGINX performance, and monitor the OS, PHP-FPM, Docker containers, and more. A unique feature in Amplify is a static analyzer for your nginx configuration that comes with automatic recommendations.

Read more about NGINX Amplify here, and try it out for free.

Additional API Module in NGINX Plus

NGINX Plus provides a better way to obtain performance metrics via a specialized API module.

The API module offers a detailed set of metrics, with the primary focus on load balancing and virtual server stats. As an example, a breakdown of all HTTP status codes (1xx, 2xx, 3xx, 4xx, 5xx) is presented for server blocks; health status information is available for http or stream upstream servers. Cache metrics include hits and misses for each cache zone.

Aside from gathering an extended set of metrics, this module is also responsible for on-the-fly configuration of upstream server groups and management of the key-value variables without reloading configuration or restarting nginx.

NGINX Plus also comes with an integrated dashboard that utilizes additional metrics. The additional metrics are also available for use in NGINX Amplify.

Other Monitoring Solutions

A number of other monitoring products can collect and present NGINX metrics. The links below describe most common integration scenarios:

The post Monitoring NGINX appeared first on NGINX.

Source: Monitoring NGINX

About KENNETH 19688 Articles
지락문화예술공작단

Be the first to comment

Leave a Reply

Your email address will not be published.


*


이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.