Nginx Reverse Proxy (NRP) monitoring

nignx monitoringNginx server currently occupies one of the most popular positions in the world. It is a free, open-source, high-performance HTTP server and reverse proxy, which is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption. Unlike traditional servers, Nginx doesn’t rely on threads to handle requests. Instead it uses a much more scalable event-driven (asynchronous) architecture.

In order to monitor Nginx servers and make sure everything is running “nice and smoothly”, any sysadmin naturally has the option to turn on Nginx’s stub_stats module. However, notice that the statistics available for this popular module unfortunately often don’t convey enough information, especially if you are using Nginx as an HTTP reverse proxy or balancer.  This paper presents the possibility of using the Monitis custom monitor approach to perform online monitoring of a reverse proxy built on the Nginx server platform.

Usage approach

The possibilities for getting statistics from Nginx are very limited, but fortunately, it has a powerful feature to configure a log file. This makes it possible to create necessary statistics by configuring the log file and then watching and grabbing the monitoring data from it.

The presented monitor is divided into two parts: a watching part and a processing part.

The watching part follows the NRP monitor log and accumulates the necessary statistics. The processing part periodically reads the accumulated statistics, executes necessary calculations and sends them to the Monitismainserver.  Then you can simply see the NRP status online on your Monitis account dashboard.

Usually it is important to know while monitoring NRP what the input load is on the NRP server, how this load is divided between target servers and what the percentage of successful responses is, from the target servers.

The current monitor calculates and shows the following metrics:

  1. The input load to NRP (in_load)
    The number of requests which were received, divided by the observation time
  2. The load redirected to destination host 1 (out1_load)
    The number of requests redirected to destination host 1, divided by the observation time
  3. The load redirected to destination host 2 (out2_load)
    The number of requests redirected to destination host 2, divided by the observation time
  4. The percentage of requests which  were redirected to destination host 1 (out1_reqs)
  5. The percentage of requests which  were redirected to destination host 2 (out2_reqs)
  6. The percentage of successfully processed requests by destination host 1 (out1_2xx)
    The number of responses with a successful status code (2xx) relative to the total number of requests to destination host 1
  7. The percentage of successfully processed requests by destination host 2 (out2_2xx)
    The number of responses with a successful status code (2xx) relative to the total number of requests to destination host 2
  8. The common estimation of NRP state (status)

○     OK – normal working state

○     IDLE – idle state (don’t receive any requests)

○     DEAD – NRP is down (Nginx process isn’t found)


Notice that metrics 4 and 5 show the real distribution of requests between destination hosts. Their sum always should equal 100%.

NRP monitor log file configuration

The Nginx log format is very flexible, so you can build it by using a lot of Nginx runtime variables. To prepare your ownlogfile there are two directives:

log_format <name> <format pattern>
access_log <path> <[format name [buffer=size]] |> [off]

The log_format directive describes the format of a log entry. Most of the variables can be used to format a log file pattern. The access_log directive sets the path, format and buffer size for the access log file.

For example, the “Own log” file can be declared as follows:

# Own log format
log_format own ‘ $time_local | $server_name | $request_length ‘;
# Own access log
access_log /var/log/nginx/monitor.log own;

It was decided that this monitor log file should have the following format:

<status code>#<responding host address>  e.g.  404#

To do this, we have to add 2 additional lines in the “/etc/ngnix/sites-available/default” config file near the definition of Nginx standard log files in the ngnix server block to define a new log file “monitor.log” like the following:

# definition of new log file format

log_format monitor '$upstream_status#$upstream_addr';

# specification of location for new log file

access_log /var/log/nginx/monitor.log monitor;

NRP monitor customization

The monitor consists of two main scripts – the watching and accumulating script (called and the processing script (called that periodically requests data, processes it and sends it to Monitis. Besides these, there is the Monitis OpenAPI wrapper script (called and few serviced scripts. Thus, as you can see, it was fully implemented by using Linux Bash scripts.

To use it you should tune it by replacing some parameters (constants) by your own – APIKey, ServiceKey, HRP host IP, Target servers IPs, and so on. For detailed instructions you can look through the sourcecode.

NRP monitor test

The simplest configuration was chosen for testing of the reverse proxy.

Two destination hosts were simulating responses by generating random status codes with normal probability distribution and with mean value – 2xx successful code. The input load was generated by an HTTP generator which provided a load on NRP of about 1 request per second.

NRP was tuned to round-robin distribution so that the input load should have been distributed equally between the designated hosts. As result we got the following monitoring table in our Monitis account:

Notice that during the test the NRP was restarted. The monitor detected this and marked it as NRP DEAD status.

Double-clicking on any line will show more detailed additional information:

Double-clicking on the DEAD status line shows the following:

Naturally, it is possible to look at the graphical presentation of the monitored data:

This graph shows the distribution of requests between the two destination hosts. As you can see, the distribution of requests is done almost equally and the curves fluctuate around 50%, which is normal for our tests.

You can find the source code in our Monitis Exchange at GitHub.