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
to the existing location
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 NGINX monitoring extension for AppDynamics
- Datadog-NGINX integration
- NGINX monitoring with Dynatrace
- The NGINX plugin for New Relic
- The NGINX plugin for Pingdom Server Monitor
- Prometheus HTTP exporters and integrations
The post Monitoring NGINX appeared first on NGINX.
Source: Monitoring NGINX