Varnish has a set of command line tools and utilities to monitor and administer Varnish. These are:
- varnishncsa: Displays the varnishd shared memory logs in Apache / NCSA combined log format
- varnishlog: Reads and presents varnishd shared memory logs.
- varnishstat: Displays statistics from a running varnishd instance.
- varnishadm: Sends a command to the running varnishd instance.
- varnishhist: Reads varnishd shared memory logs and presents a continuously updated histogram showing the distribution of the last N requests by their processing.
- varnishtop: Reads varnishd shared memory logs and presents a continuously updated list of the most commonly occurring log entries.
- varnishreplay: Parses varnish logs and attempts to reproduce the traffic.
For further information and example of usage, please refer to the man-pages.
This command shows the most often-made requests to the backend:
It’s excellent for spotting often-requested items that are currently not being cached. The “-b” flag filters for requests made to the backend. “-i TxURL” filters for the request URL that triggered the request to the backend. Its output looks something like this:
Top of the list, most often-requested URL from the backend. A prime candidate for caching.
Here are some more examples of useful varnishtop queries:
Show all request URLs coming into Varnish.
# varnishtop -ndr upal -i RxURL
Show all request URLs going to Varnish's backend.
# varnishtop -ndr upal -i TxURL
Show all User-Agent request headers.
# varnishtop -ndrupal -i RxHeader -I User ggent
Show all Content-Type response headers from a backend.
This command hows a histogram for the past 1000 requests, whether they were cache hits (denoted by a ‘|’) or misses (denoted by a ‘#’), and how long the requests took to process (further to the right, longer time). It’s good for a high-level view of how the server is doing under load.
This command displays all varnish traffic for a specific client. It’s helpful for seeing exactly what a particular page or request is doing. Set it to your workstation IP, load the page, see everything Varnish does with your connection including hit/miss/pass status. Varnishlog is really useful, but it puts out an overwhelmingly-large amount of data that isn’t easily filtered. The “-o” option groups all of the entries for a specific request together (without it all entries from all requests are displayed fifo) and it accepts a tag (”ReqStart” in this example) and regex (the IP address in this case) to filter for only requests associated with that tag & regex. It’s the only way I’ve found to filter down the firehose of log entries into something useful.
Watch that RAM, or “vmstat, oh how I love thee!”
Varnish can eat RAM like there’s no tomorrow. Be careful and be sure to configure its max memory to be something less than your available RAM. I forgot when I first set things up. The system worked great for a while, and then took a nosedive as the Varnish cache ate up all the available RAM and pushed the system into a swap death spiral.