Monitoring

Statistics

vha-agent can be configured to output a few counters to a file specified on the command line via the -s argument. The file will be updated every stat_intvl second.

time=1410191768
uptime=22
last_reload_time=1410191760
n_trans=7
n_insert=1
n_dropped=0
n_req_total=1
n_req_failed=0
n_backlog=0
n_reload_total=2
n_reload_failed=1

• time is a UNIX timestamp for when the file was last updated.
• uptime is time elapsed in seconds since starting vha-agent.
• last_reload_time is the time of the last configuration reload.
• n_trans is the number of VSL transactions processed.
• n_insert is the number of VSL transactions in which we found a new object had been inserted.
• n_dropped is the number of requests that were dropped due to hitting backlog_max.
• n_req_total is the number of peer notifications.
• n_req_failed is the number of failed peer notifications.
• n_backlog_NAME is the length of the waiting list for node NAME.
• n_backlog is the current length of the waiting list of requests that are yet to be expedited by a worker thread.
• n_reload_total is the total number of configuration reloads ran (including failed ones).
• n_reload_failed is the number of failed configuration reloads.

Inspecting requests

VHA is heavily based on HTTP, and uses headers to communicate various aspects of the replication. This section list and explain each one of them. You can check that requests are actually transiting through a Varnish instance using varnishlog, filtering with the -q argument:

varnishlog -q "ReqHeader ~ x-vha"

The different headers are:

• x-vha-origin: contains the address, name and cluster of the VHA agent that initiated the replication request. The address is used with vmod_goto to set the backend to that originating node.
• x-vha-done: lists all the clusters that have been/will be processed, to avoid replicating twice to the same cluster. For cross-cluster replication, the current cluster is suffixed with “*”, sign that local replication is allowed for this cluster.
• x-vha-fetch: is only used by the VCL part, and denotes that the request is in its Varnish-to-Varnish phase (as opposed to VHA-to-Varnish). This allows to disable esi processing by Varnish and ensure that ESI fragments are replicated individually.
• x-vha-token: added by VHA if the -T option is specified. It contains a secret token that will be verified by the receiving Varnish to make sure the request can be trusted.