One way to get more information from inside Nginx is this open source module published on GitHub at https://github.com/vozlt/nginx-module-vts.

The author was clearly inspired by the official ngx_http_status features and even used the same structures and dashboard client-side code (although the older version). This may be actually a good thing because you can start integrating nginx-module-vts and then transfer all the scripts with minimal modifications to Nginx Plus once you are ready for the subscription. The documentation is wonderful, and there are many examples. Some of the keys in the JSON objects that are returned by this module differ from the official ngx_http_status keys, and because of this, we would recommend abstracting the actual key names in your monitoring configuration files.

Another alternative to the great official ngx_http_status is the Luameter package, which is a collection of scripts in the Lua programming language that integrates with Nginx using the ngx_http_lua module. The format of the data collected and exported by Lua is also clearly inspired by the official and pricey alternative, so you will be able to switch with little effort.

The idea of the very useful ngx_http_lua module is to let Nginx administrators hook snippets of custom Lua code into different phases of request processing.

Luameter is distributed on a pay-as-you-go model, so it is not free. The lowest price is just 10 US dollars, so it is very cheap in comparison with what the commercial arm of Nginx sells. Refer to https://luameter.com/ for all the information about Luameter.

This is another collection of scripts in Lua. It may be used by itself to collect and export online statistics about the number of generated HTTP responses with various HTTP status codes, but it is even more valuable as an example of using Lua hooks to collect additional data and report it.

The code is published on GitHub at https://github.com/yandex-sysmon/nginx-lua-stats.

nginx-lua-stats works its magic by setting up a hook on the logging phase, which collects the data, and then setting up another hook on the content generation phase for a particular location which is able to actually generate a full HTTP response with the collected statistics.

Here is the relevant part of the nginx.conf file:

 location /stat {
       content_by_lua_file 'show_stat.lua';
    }

    location /html {
      log_by_lua_file 'collect_stats.lua';
    }

The requests to the /stat location will return the collected data. The second location block installs an additional log handler which is actually a counting hook. The effect is that all requests for the documents under /html hierarchy will invoke the collect_stats.lua script as part of the logging phase.

One of the many advantages of open source development models is the possibility of forks, which are separate versions of the main software with changes that are not accepted by the original author. Sometimes, forks become very successful in their own right and even supersede the original versions. One of the biggest Chinese websites Taobao has its own Nginx fork, which is named tengine. There are a number of big websites beside Taobao that prefer tengine to the original Nginx. Tengine has some rather advanced features for upstream management and monitoring.

The upstream_check module allows us to specify some custom health checks for all the hosts in an upstream group. That is an interesting functionality by itself, but it is the secondary feature that got the module in this chapter. The directive check_status inside a location is a content generator such as the status and stub_status of the official modules that we discussed at length in this chapter.

This directive provides a report on the health of different hosts in an upstream group in either human-readable HTML or machine-readable JSON or even CSV format.

See the examples of configuration and output at http://tengine.taobao.org/document_cn/http_upstream_check_cn.html.

There is a patch for a very old Nginx version that adds one very interesting metric to the ngx_http_stub_status output. The metric is the requests rate that otherwise may be only approximately calculated using saved past state from the main total requests counter.

The patch is available at http://catap.ru/patches/nginx/request_per_seconds.dpatch.

Unfortunately, it does not apply cleanly to modern Nginx source, so you will have to do some manual conflict resolution.

There is also another piece of rather old code that may or may not be brought up to date with modern Nginx. It is called Ustats, and it is officially put into the "abandonware" category. Such projects may provide a starting point for some in-house development efforts. See https://github.com/0xc0dec/ustats for the code and https://code.google.com/p/ustats/ for some documentation.