NGINX VTS (NGINX Virtualhost Traffic Status) is a module for NGINX that provides an API and web interface for monitoring NGINX server activity and performance. It collects and displays key metrics such as requests per second and response time, and can be used to track the health and performance of NGINX servers over time. The module also provides detailed request and response logging, allowing for easy debugging of potential issues.
The prerequisites for monitoring NGINX VTS with Netdata are to have NGINX VTS and Netdata installed on your system.
Netdata auto discovers hundreds of services, and for those it doesn’t turning on manual discovery is a one line configuration. For more information on configuring Netdata for NGINX VTS monitoring please read the collector documentation.
You should now see the NGINX VTS section on the Overview tab in Netdata Cloud already populated with charts about all the metrics you care about.
Netdata has a public demo space (no login required) where you can explore different monitoring use-cases and get a feel for Netdata.
Requests total is the total number of requests received by the NGINX server per second. This metric is important to monitor in order to understand how much traffic the server is receiving, and to ensure that the server is not getting overloaded. High values could indicate that the server is overloaded and needs to be scaled to handle the increased load.
Active connections is the total number of active connections to the NGINX server at any given time. This metric is important to monitor in order to ensure that the server is not overloaded, and to understand the current load on the server. High values could indicate that the server is overloaded and needs to be scaled to handle the increased load.
Connections total is the total number of connections to the NGINX server per second, broken down into the different connection states: reading, writing, waiting, accepted, and handled. This metric is important to monitor in order to ensure that the server is not overloaded, and to understand the current load on the server. High values could indicate that the server is overloaded and needs to be scaled to handle the increased load.
Uptime is the total amount of time that the NGINX server has been running. This metric is important to monitor in order to ensure that the server is up and running, and to identify any potential issues with the server.
SHM usage is the total amount of shared memory used by NGINX in bytes, broken down into max and used. This metric is important to monitor in order to ensure that the server is not running out of memory and to identify any potential memory issues.
SHM used node is the total number of nodes used by NGINX in shared memory. This metric is important to monitor in order to ensure that the server is not running out of memory, and to identify any potential memory issues.
Server requests total is the total number of requests received by the NGINX server per second. This metric is important to monitor in order to understand how much traffic the server is receiving, and to ensure that the server is not getting overloaded. High values could indicate that the server is overloaded and needs to be scaled to handle the increased load.
Server responses total is the total number of responses sent by the NGINX server per second, broken down into the different response codes: 1xx, 2xx, 3xx, 4xx, and 5xx. This metric is important to monitor in order to understand how well the server is responding to requests, and to identify any potential issues with the server.
Server traffic total is the total amount of data sent and received by the NGINX server per second, broken down into in and out. This metric is important to monitor in order to understand how much traffic the server is receiving and sending, and to identify any potential issues with the server.
Server cache total is the total number of cache events per second, broken down into miss, bypass, expired, stale, updating, revalidated, hit, and scarce. This metric is important to monitor in order to understand how well the server is caching content, and to identify any potential issues with the server’s caching performance.
Want a personalised demo of Netdata for your use case?