Update: Nginx monitoring is now generally available!

Over the past few weeks the Ruxit team has run an early-access program for Nginx service- and process-monitoring. It’s now time to release the beta version of Ruxit Nginx monitoring support to the public. Beginning with Ruxit, v1.77, Nginx service and process monitoring can be manually enabled either for all or individual hosts.

To enable Nginx monitoring for all hosts in your environment:

  1. Confirm that you are running a version of Ruxit Agent no older than v1.75.
  2. Go to Settings > Monitored technologies.
  3. Set the Nginx slider to the On position.
    Nginx monitored technologies 1
  4. Restart all your Nginx instances to enable detection and monitoring of Nginx processes.

To enable Nginx monitoring for individual hosts:

  1. Confirm that you are running a version of Ruxit Agent no older than v1.75.
  2. From the Ruxit homepage, click the Hosts tile.
  3. Select the host you want to configure.
  4. Click Edit on the menu bar.
  5. Set the Nginx slider to the On position.
    Monitored host Nginx
  6. Restart the Nginx instance to enable detection and monitoring of Nginx processes.

Nginx service monitoring and process metrics

Ruxit monitoring provides important Nginx metrics like Requests per second, average Response size per request, and Active connections along with CPU and Memory metrics. Spikes in Requests per second may indicate benign events (for example, increased customer activity) or serious events (for example, a DDoS attack). Spikes can also be caused by errors in upstream servers. For example, if Nginx is load balancing a set of servers and those servers go down, Nginx will quickly return errors. A decrease in the Requests per second metric may, on the other hand, be a sign of network connectivity issues or saturation of an essential system resource, like CPU or RAM.

The Accepted vs. dropped connections chart can help you fine-tune your Nginx settings. There is a configurable hard limit on the total number of connections that Nginx can handle. It’s important that you set this limit based on your environment and applications so that you have space left over for spikes, but can run Nginx with as much load as possible to reduce infrastructure costs. Once the connection limit is reached, new connections are dropped and users will experience errors. Note that this limit includes all connections, from clients and to upstream servers.

For accepted connections you can view even more detailed data:

  • Read: The current number of accepted connections from clients where Nginx reads the request.
  • Write: The current number of connections from clients where Nginx writes a response back to the client.
  • Wait: The current number of connections from clients that are in the Idle / Waiting state (i.e., waiting for a request). This is the state that keepalive connections remain in after handling a request and before receiving the next request.

On each Ruxit Service page you will now see response times and failure rates for Nginx-based services. Ruxit uses your configured virtual servers (server_name directive) for service detection, however only meaningful values for server_name are populated as separate services. If a server_name directive includes values like _, localhost, or * the service is grouped into a service that has the same name as the host name.

Nginx metrics Nginx services

Automatic injection of real user monitoring JavaScript tag

One cool feature of Ruxit Nginx beta monitoring support is that Ruxit Agent automatically injects the real user monitoring JavaScript tag into Nginx processes. This means you can start real user monitoring without changing any of your code—there’s no need to have your development team add even a single line of code. You automatically receive real user data for all applications running behind your Nginx servers—even backend servers where Ruxit has not yet been installed.

Nginx RUM injection

If you decide later to install Ruxit Agent on your backend servers, you can decide if you want to inject the real user monitoring JavaScript tag on Nginx or on the backend servers. Even manual injection is still possible, but for a quick start we recommend the automatic JavaScript tag injection approach.

Nginx automatic RUM injection

Supported Linux distributions and Nginx package sources

Beginning with Ruxit Agent v1.77, Ruxit supports the open source versions of Nginx for Linux, versions 1.41.9.

Unfortunately Nginx does not currently support Dynamic Module Loading (DSO) like Apache. Any module that needs to be added to Nginx must be added at Nginx compile time. This architecture brings a small limitation to Ruxit: Ruxit Agent needs to know which binary is used so that it can inject the Ruxit Nginx performance monitoring module at runtime. We don’t want to leave you with the work of rebuilding your Nginx so that you can have premium Nginx monitoring, so we’ve built a runtime injection of Ruxit Agent for the most common Nginx binaries.

Ruxit currently supports more than 450 binary builds from various package sources for Nginx versions 1.4 to 1.9 for the following Linux distributions:

  • Ubuntu, beginning with 10.04
  • CentOS 5,6,7
  • Red Hat Enterprise Linux 5, 6, 7
  • Amazon

If your Nginx build (binary) isn’t supported, you will see the following message:

Nginx binary not supported

If your binary isn’t supported, please open a support ticket  so that we can add it to our list of known and tested binaries.

Supported Nginx package sources: