Varnish

Varnish 4 CLI Programs, Tips and Tricks

by , , revisited on


We have by far the largest RPM repository with dynamic stable NGINX modules and VMODs for Varnish 4.1 and 6.0 LTS. If you want to install NGINX, Varnish, and lots of useful modules for them, this is your one-stop repository to get all performance-related software.
You have to maintain an active subscription in order to be able to use the repository!

Log website requests in a detailed format using varnishlog

The varnishlog utility allows you to get requests as they arrive and also fetch some recent ones from memory. It produces log entries in a very detailed format. This helps with debugging how things are being processed by Varnish.

Log all PURGE and BAN requests

varnishlog -g request -q 'ReqMethod eq "PURGE" or ReqMethod eq "BAN"'

If you want to take a look at recent PURGE requests which already took place (stored in memory), then add the -d switch:

varnishlog -d -g request -q 'ReqMethod eq "PURGE"'

Log all client requests to specific website (virtual host) continuously

varnishlog -q "ReqHeader ~ '^Host: .*\.example.com'"

Log all backend requests from Varnish (to nginx)

varnishlog -q "BereqHeader ~ '^Host: .*\.getpagespeed.com'"

Armed with varnishlog, you can solve the "Backend fetch failed" errors easily!

varnishncsa

So you have tried varnishlog and you see that it’s more targeted towards debugging requests, and the logging is very detailed. If you want to see requests coming to your Varnish instance in a compact form that is similar to Apache or nginx logs, meet varnishncsa.

It accepts all the same arguments as varnishlog. Example:

varnishncsa -g request -q 'ReqMethod eq "PURGE"'

Filter specific User-Agent requests

E.g. you may want to check how W3TC WordPress plugin sends purge requests to Varnish:

varnishlog -q "ReqHeader ~ '^User-Agent: W3 Total Cache'"

Show requests behind SSL terminator

You’d mostly always use Varnish behind an SSL terminator, e.g. nginx. If you use varnishncsa, you’ll see that it shows nginx IP address (127.0.0.1) instead of the actual visitor’s IP address. Here’s a good way to “fix” the output of varnishncsa by showing the value of X-Forwarded-For header:

varnishncsa -F '"%{X-Forwarded-For}i" %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i"'

This is hard to memorise. So it’s better to create a permanent alias so you can just type varnishncsa to invoke the command with proper parameters:

cat << EOF > /etc/profile.d/varnishncsa.sh
alias varnishncsa='varnishncsa -F "'%{X-Forwarded-For}i' %l %u %t '%r' %s %b '%{Referer}i' '%{User-agent}i'"'
EOF
chmod 0644 /etc/profile.d/varnishncsa.sh
source /etc/profile.d/varnishncsa.sh

varnishtop

The following example displays a continuously updated list of the most commonly used user agents:

varnishtop -C -I ReqHeader:User-Agent

Clear Varnish cache for domain using command line

sudo varnishadm "ban req.http.host ~ www.mydomain.com"

Varnish and WordPress

If you put WordPress with Nginx behind Varnish, you will likely find JetPack not working.
This is the quick fix:

$_SERVER['SERVER_PORT'] = 80;

This is noted to be quick fix only. What you really should be doing is map port related variable for FastCGI configuration in PHP-FPM. (We got this covered in our server setup services).

If you got “Backend fetch failed” error when activating JetPack in WordPress, there is a fix for Varnish and Jetpack that we have covered in a separate post.

List all backends

The command allows to check for defined backends:

varnishadm backend.list

Example output:

Backend name                   Admin      Probe
boot.default                   probe      Healthy 5/5
boot.extras_getpagespeed_com   probe      Healthy 5/5
boot.wp_getpagespeed_com       probe      Healthy 5/5

So this shows related probe and it’s health status as well.

You may want to use result of the command to check if any backends are sick. Creative sysadmins may even want to add that as monitoring jobs for Monit to see if specific important backends are down:

varnishadm backend.list | grep Sick

Varnish Health Checks

In case you want to constantly monitor Varnish health checks in real time, there’s command for that too. The nice command to troubleshoot health probes:

varnishlog -g raw -i Backend_health

TIP: You can actually have both Apache and Varnish run on the same port 80. But for this trick you need to bind them to different interfaces, i.e. Apache to 127.0.0.1:80 while Varnish to 123.123.123.123:80

TIP for WordPress users: behind load balancer (varnish) and/or at least with Nginx SSL termination, you may want to uncheck Page Cache in W3TC (W3TC won’t clear its own cache upon posting from WordPress.com because of a bug).

Varnish health, backends, and polling:

https://www.varnish-cache.org/trac/wiki/BackendPolling
https://www.varnish-cache.org/docs/3.0/tutorial/handling_misbehaving_servers.html#tutorial-handling-misbehaving-servers

Detailed here: http://book.varnish-software.com/4.0/chapters/Saving_a_Request.html

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.