Varnish is an open source, high-performance HTTP accelerator designed for content-heavy websites. It helps websites to deliver content faster by caching static content and allowing dynamic content to be served from memory. Varnish is often used in conjunction with Apache HTTPd to improve performance and scalability for websites.
The prerequisites for monitoring Varnish Cache with Netdata are to have Varnish Cache 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 Varnish Cache monitoring please read the collector documentation.
You should now see the Varnish Cache 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.
The rate at which connections to the Varnish server are established. It is important to monitor this metric because it provides an indication of how many active connections there are to the server, and therefore how much load the server is being put under. If the rate of connections is too high, it may indicate an issue with the server or the application that is causing excessive requests. Normal values should be in the range of hundreds to thousands of connections per second, depending on the size and type of the application.
The rate of requests that are being made to the Varnish server. This metric is important to monitor because it indicates the amount of load that is being put on the server, and can help identify any issues with requests that may be causing excessive load.
The rate at which requests are being answered from the Varnish cache. This metric is important to monitor because it provides an indication of how effectively the cache is being used, and can help identify any issues with caching that may be causing excessive requests. Normal values should be in the range of 80-90%, indicating a high hit rate.
The rate at which requests are being answered from the Varnish cache in the current polling interval.
The rate of objects that have expired in the Varnish cache.
The rate of objects that have been removed from the Varnish cache due to the cache being full. This metric is important to monitor because it indicates the amount of objects that are being removed from the cache due to the cache being full, and can help identify any issues that may be causing excessive removal of objects. Normal values should be in the range of zero to a few objects per second.
The number of threads in the Varnish server pools.
The Threads Statistics metric measures the rate of threads that are being created and destroyed in the Varnish server pools.
The number of requests that are queued up in the Varnish server. This metric indicates the amount of load that is being put on the server, and can help identify any issues with requests that may be causing excessive load. Normal values should be in the range of zero to a few hundred requests.
The rate at which connections are being established to the backend servers. This metric is important to monitor because it provides an indication of how much load the backend servers are being put under. If the rate of connections is too high, it may indicate an issue with the backend server or the application that is causing excessive requests. Normal values should be in the range of hundreds to thousands of connections per second, depending on the size and type of the application.
The rate of requests that are being made to the backend server. This metric indicates the amount of load that is being put on the backend server, and can help identify any issues with requests that may be causing excessive load. Normal values should be in the range of hundreds to thousands of requests per second, depending on the size and type of the application.
The rate of errors that occur during Edge Side Includes (ESI) processing. This metric indicates any issues with the ESI processing that may be causing errors. Normal values should be in the range of zero to a few errors per second.
The amount of memory that is being used by the Varnish server.
The amount of time that the Varnish server has been running.
The rate of responses from the backend server to the Varnish server. This metric is important to monitor because it indicates the amount of load that is being put on the backend server, and can help identify any issues with requests that may be causing excessive load. Normal values should be in the range of hundreds to thousands of kilobits per second, depending on the size and type of the application.
The amount of storage that is being used by the Varnish server. This metric is important to monitor because it indicates the amount of resources that are being used by the server, and can help identify any issues that may be causing excessive resource usage. Normal values should be in the range of several hundred kilobytes to several gigabytes, depending on the size of the application.
The number of objects that have been allocated in the Varnish server. This metric is important to monitor because it indicates the amount of resources that are being used by the server, and can help identify any issues that may be causing excessive resource usage. Normal values should be in the range of several hundred to several thousand objects, depending on the size of the application.
Want a personalised demo of Netdata for your use case?