Month: March 2014

Dry-run compiling

The first step to debug your varnish configuration is to simply ‘dry-run’ compiling it:

varnishd -Cf /etc/varnish/myconf.vcl

The output of this command will either be a successfully-compiled VCL or an error message telling you on what line the error occurs. Most of the time that enough to fix syntax error.

Add message into syslog

Since branch 3.X varnish can load and use additional module. One of the most useful is the std module. You can use it to add “trace” message into the syslog:

import std;

vcl_recv {
  ...
  std.syslog(0, "Cookie content: " + req.http.Cookie);
}

Use varnishlog

varnishlog is a command line utility that display all varnishd ‘internal’ activities: request handling, request processing, backend checks/request, hash information, objects caching/retrieving, etc… As you can imagine, the output is extremely verbose and kind of frightening. But you can add parameters, to filter it.

For example, to display only hashes:

varnishlog -c -i Hash

To display only ‘User-Agent’ strings:

varnishlog -c -i RxHeader -I User-Agent

To display only POST requests:

varnishlog -c -m RxRequest:POST

To display only request with a 404 response:

varnishlog -c -m TxStatus:404

To filter requests for a specific URL:

varnishlog -c -m RxURL:"/foo/bar.php"

To filter URLs asked to the backend:

varnishlog -b -i TxURL

To filter for a particular IP:

varnishlog -c -o ReqStart 192.168.1.16

Monitoring activities with varnishtop

Another interesting command line tool is varnishtop. Like varnishlog it reads varnishd shared memory logs but instead of displaying current entries, it presents a continuously updated list of the most commonly occurring entries. Like varnishlog you can add additional parameters to filter it output.