Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Getting more status data from Nginx

In this section, we will explore the ways to get more information about an Nginx instance so that the monitoring can be more extensive and cover more details.

In 2014, Nginx creators launched a commercial umbrella company for the open source Nginx software, which started to explore the business models around the server. One of the most anticipated features was comprehensive monitoring and the developers delivered on that front.

The commercial product of Nginx company is named Nginx Plus. It is a subscription service marketed to medium and large businesses already dependent on Nginx for their infrastructure. Nginx Plus pricing is based on yearly licenses per single instance and is rather aggressive, which also means that once you need these features, you already have several instances and need several licenses. For complete and up-to-date information, refer to the Nginx Plus web page at https://www.nginx.com/products/.

One of the most important part of the subscription is the availability of the new status module, which is named ngx_http_status, and is a kind of elder brother for the open source ngx_http_stub_status that most of the monitoring solutions we described depend on.

Along with programmatic access to the status data in machine-readable form, Nginx Plus provides a beautiful and expressive dashboard that you can use without any integration into your enterprise monitoring. The https://www.nginx.com team kindly provides a demonstration of what the dashboard can do at http://demo.nginx.com/status.html.

The configuration for the ngx_http_status module looks like this:

location /status {
    status;
}

As you can see, it is an almost exact copy of what we did earlier for stub_status, but the main directive is now more aptly named status. This location will accept a number of different requests. It provides a hierarchy of information about different objects, such as upstreams and cache zones.

The built-in dashboard is actually a one-page HTML application that retrieves all the information it needs from /status. The static HTML will be installed with the Nginx Plus distribution. On Debian-based systems, you can find it at /usr/share/nginx/html/status.html. To add the dashboard to your Nginx Plus instance, see this configuration example:

location = /status.html {
    root /usr/share/nginx/html;
}

Having your own Nginx dashboard is never enough because if you invested into Nginx Plus subscription you probably have some business-critical operations and you need automatic monitoring. At the same time, the dashboard is the perfect way to explore the information that is exported by Nginx Plus. The ngx_http_status module provides wealth of information in machine-readable format (JSON or JSONP) to integrate with all the systems we mentioned earlier. And using the new metrics available, you will be able to monitor more. Let's dig deeper into what ngx_http_status returns by default:

$ curl http://localhost/status
{"version":6,"nginx_version":"1.9.4","address":"127.0.0.1","generation":4,"load_timestamp":1448573854895,"timestamp":1448573864361,"pid":3691,"processes":{"respawned":0},"connections":{"accepted":208,"dropped":0,"active":1,"idle":1},"ssl":{"handshakes":0,"handshakes_failed":0,"session_reuses":0},"requests":{"total":8309,"current":1},"server_zones":{"localhost_http":{"processing":1,"requests":12,"responses":{"1xx":0,"2xx":11,"3xx":0,"4xx":0,"5xx":0,"total":11},"discarded":0,"received":3305,"sent":7756}},"upstreams":{},"caches":{}}
$

As you can see, the default output format for this module is JSON, which allows much more complex data structures. The same data re-indented for readability looks like this:

{
   "version":6,
   "nginx_version":"1.9.4",
   "address":"127.0.0.1",
   "generation":4,
   "load_timestamp":1448573854895,
   "timestamp":1448573864361,
   "pid":3691,
   "processes":{
      "respawned":0
   },
   "connections":{
      "accepted":208,
      "dropped":0,
      "active":1,
      "idle":1
   },
   "ssl":{
      "handshakes":0,
      "handshakes_failed":0,
      "session_reuses":0
   },
   "requests":{
      "total":8309,
      "current":1
   },
   "server_zones":{
      "localhost_http":{
         "processing":1,
         "requests":12,
         "responses":{
            "1xx":0,
            "2xx":11,
            "3xx":0,
            "4xx":0,
            "5xx":0,
            "total":11
         },
         "discarded":0,
         "received":3305,
         "sent":7756
      }
   },
   "upstreams":{ },
   "caches":{ }
}

On the upper level of the return JSON object, we see these items:

`version`	This is the version of the format of these data. It is important for parsers because some of the items only appeared starting from a specific version, and you may require Nginx upgrade to get enough information for your parser. As of December 2015, the last version of this is 6.
`nginx_version`	This is the version of Nginx software.
`address`	This is the IP address of the server generating the status report.
`generation`	This gets incremented by one each time you reload Nginx configuration. So in a sense, this is the number of the current configuration generation. One may wonder why the generation number is important. One of the reasons is that it may not be practical to compare some indicators, for example, performance if the generation and therefore the configuration has changed.
`load_timestamp`	The Unix epoch timestamp of the last configuration reload.
`timestamp`	Current UNIX timestamp.
`pid`	The process identifier of the worker that processed this specific status request.
`processes`	This is an object with a single field (it may be extended in future versions of the response structure), which is named `respawned`, and contains the number of all child processes that we restarted after a failure.
`connections`	This is an important object containing the information that we otherwise can obtain via the open source `ngx_http_stub_status` module.
`connections.accepted`	This value inside the `connections` object is the total number of all accepted client connections.
`connections.dropped`	This is the total number of dropped connections. Note that with `http_stub_status` module, we have to calculate this value ourselves.
`connections.active`	The number of currently active connections.
`connections.idle`	The number of connections that are idling.
`ssl`	This is also an object with several values inside. Those are SSL (actually, TLS) counters. SSL is an older version of the protocol for encrypted connections. The proper name for the current protocol is TLS, but the old name is still used by some conservative specialists.
`ssl.handshakes`	The total number of TLS handshakes.
`ssl.handshakes_failed`	The total number of unsuccessful TLS handshakes. This is a very interesting and important value that is not available via `http_stub_status` while being rather critical to monitor.
`ssl.session_reuses`	Each TLS handshake is an expensive operation, and there is an optimization that reuses one of the previously established TLS sessions to avoid the handshake altogether. A low number here means an opportunity to increase performance with little investment.
`requests`	An object with two values.
`requests.total`	This is the same number that is printed last on the third line of the `http_stub_status` output. The global counter for all client requests received via all connections.
`requests.current`	The number of currently processed requests.
`upstreams`	If there is one important feature of Nginx Plus that you want to name to justify the purchase, it should probably be the upstreams object in the `http_status` output. It allows the metrics of the individual upstreams and hosts inside upstreams to be monitored. The example host mentioned earlier does not have any upstreams configured, and this is why the object is empty.
`caches`	This object contains the status of all configured caches. Most of the cache configuration is done with the upstream directives.
`server_zones`	This object is a custom storage that you can fill with data using the `status_zone` directive inside one of your server blocks. Status zones are a new concept in Nginx Plus. They provide an additional level of flexibility in collecting status data. You can find comprehensive documentation on this directive at http://nginx.org/en/docs/http/ngx_http_status_module.html#status_zone.

Each of the server zones contains a separate multilevel object with the status information collected from all servers connected to the same status zone. That object looks like this:

`processing`	The snapshot number of currently processed requests.
`requests`	The total counter of all requests.
`responses.total`	The number of responses sent to clients. Should be close to the number of requests.
`1xx`	The number of responses with HTTP 1xx status codes.
`2xx`	The number of responses with HTTP 2xx status codes.
`3xx`	The number of responses with HTTP 3xx (usually redirects) status codes.
`4xx`	The number of responses with HTTP 4xx (usually indicating bad requests that should be fixed on the client side) status codes.
`5xx`	The number of responses with HTTP 5xx (meaning internal server errors) status codes.
`discarded`	The number of requests that did not generate responses.
`received`	Total bytes received from clients.
`sent`	Total bytes sent to clients.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Getting more status data from Nginx

Create new playlist

Sign In

Sign Up

Getting more status data from Nginx

Table of Contents for
Getting more status data from Nginx