Varnish

Auto-Detection

Health Check

Built-in Metrics

Varnish is a high-performance HTTP accelerator and reverse proxy that sits in front of web servers to make websites and APIs load much faster.

Auto-Detection

Glouton detects Varnish by its process, creates a service check by default on port 80, falling back to 6081 — the port Debian’s package listens on. If the auto-detected parameters are incorrect, you can override them manually.

Linux

sudo tee /etc/glouton/conf.d/99-varnish.conf > /dev/null << 'EOF'
service:
  # For a Varnish running outside a container
  - type: "varnish"
    address: "127.0.0.1"
    port: 6081

  # For a Varnish running in a Docker container
  - type: "varnish"
    instance: "CONTAINER_NAME"
    port: 80
EOF

Windows

Varnish does not run on Windows.

Glouton automatically detects configuration changes.

How the Metrics are Read

Varnish publishes its counters in a shared memory segment with no socket in front of them, so there is nothing for Glouton to connect to: the only way to read them is to run varnishstat. Glouton runs it itself, and needs no exporter and no credentials.

• Varnish on the host — Glouton runs varnishstat from the machine, asking for root where that is needed.
• Varnish in a container — Glouton runs varnishstat inside that container, so the container’s own image must carry it. The official image does. Glouton checks this before collecting anything (varnishstat -V), and creates no input when the command is missing.

Varnish metrics are collected every 60 seconds. That is because every gather runs an external command: varnishstat, through sudo on the host and through the container runtime otherwise. Rates such as varnish_cache_hit are averaged over that minute.

Service Check

Glouton performs an HTTP service check on the Varnish port (default 80 or fallback to 6081).

Metric	Description
service_status	Status of Varnish

Built-in Metrics

Metric	Description
varnish_cache_hit	Number of Varnish cache hits, per second
varnish_cache_miss	Number of Varnish cache misses, per second
varnish_cache_hit_perc	Varnish cache hit percentage
varnish_cache_evictions	Number of Varnish cache evictions, per second
varnish_backend_fail	Number of failed Varnish backend connections, per second
varnish_threads	Number of Varnish worker threads
varnish_threads_limited	Number of times Varnish hit its worker thread limit, per second
varnish_sessions_queued	Number of Varnish sessions queued for a worker thread, per second
varnish_sessions_dropped	Number of Varnish sessions dropped for lack of a worker thread, per second
varnish_uptime	Varnish uptime

Monitoring Troubleshooting

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The Service Check is not OK

The check is an HTTP request to the Varnish port, so beyond the usual Connection refused and connection timed out after 10 seconds it also fails on an unexpected status code. The status code comes from the backend app, not from Varnish. A 404 on / or a 503 from a VCL routing on Host is fixed with http_path / http_host on the service.

A failing check does not stop the metrics: they are read from varnishstat, not over HTTP.

Metrics are Missing

Reproduce what Glouton does, from the machine where the agent runs:

sudo varnishstat -1                                      # Varnish on the host
docker exec CONTAINER_NAME /usr/bin/varnishstat -1       # Varnish in a container

What you see	Cause	Fix
varnishstat: command not found in a container	The container’s image does not ship varnishstat or the path is not correct	Use an image that does — Glouton needs the command to be known at /usr/bin/varnishstat and run it from inside the container for metrics
Can't open VSM file	varnishstat cannot reach the daemon’s shared memory	Run it as root, and check the daemon is running
the check is green but no metric arrives	Glouton could not run varnishstat	Raise the agent log level to see why; see Troubleshoot a Service