Monitoring Varnish
Varnish is recognised by its varnishd process and read through the counters Varnish
already keeps. No VCL change, no exporter, no management port to open: the agent runs the
one-shot varnishstat -1 on the host and turns the main counters into metrics, with the
rates that matter computed on the host.
How Varnish is recognised
The varnish definition matches a running process named varnishd. Every 60 seconds the
agent executes varnishstat -1 (the binary must be on the host, no shell is involved) and
parses the MAIN.* counters. A companion logs-varnish definition follows the
varnishd and varnish identifiers in the journal every 30 seconds. A host that only has
the package installed does not match.
What is collected
Traffic and cache. Client sessions and client requests, cache hits and cache misses, all as the cumulative counters Varnish exposes. From them the agent computes per-second rates on the host (requests, hits, misses), so a chart shows traffic rather than a line that only ever climbs; the hit ratio is yours to derive from the hit and miss rates.
Backends. Two counters describe the origin side: backend_fail, connection attempts to
a backend that failed, and backend_unhealthy, requests refused because the backend was
marked unhealthy. Both are also turned into per-minute rates, which is what the shipped
rule watches.
Process. Uptime and the number of worker threads.
| Signal | Metric |
|---|---|
| Uptime, worker threads | svc.varnish.uptime, svc.varnish.threads |
| Sessions and client requests (cumulative) | svc.varnish.sessions, svc.varnish.client_req |
| Cache hits and misses (cumulative) | svc.varnish.cache_hit, svc.varnish.cache_miss |
| Backend failures and unhealthy refusals (cumulative) | svc.varnish.backend_fail, svc.varnish.backend_unhealthy |
| Requests, hits, misses per second (computed) | svc.varnish.client_req_rate, svc.varnish.cache_hit_rate, svc.varnish.cache_miss_rate |
| Backend failures and unhealthy refusals per minute (computed) | svc.varnish.backend_fail_per_min, svc.varnish.backend_unhealthy_per_min |
Names, tags and units are in the metrics reference.
Logs. Varnish's journal entries ship by default at notice level and above. Request logging in Varnish lives in shared memory rather than the journal, so it is not part of this.
Alerts out of the box
| Rule | Fires when | Severity | Ships |
|---|---|---|---|
| Varnish cannot reach its backends | one or more failed backend connections per minute, sustained 5 minutes | warning | on |
| Service floods error logs | 50 or more error lines in 15 minutes | warning | auto |
A healthy Varnish sits at zero failed backend connections. A failure that repeats every minute for five minutes is an origin that refuses or times out on live traffic, which is where visitors start seeing stale pages or errors, and five minutes rides out a single restart of the origin. The incident closes when the rate drops back under 0.5 a minute. Thresholds and hysteresis are in the rules catalog.
Limitations
- Only the
MAIN.*totals are read. Per-backend health, per-backend request counts and the ban list are not collected, so the alert tells you that some backend is failing, not which one. - The hit ratio is not computed; build it from the hit and miss rates in a chart or a custom rule.
- No version fact is collected for Varnish.
varnishstatmust be installed and readable by the agent on the same host; the probe does not talk to a remote Varnish.- A Varnish running inside a container is not matched by this definition, because containers are excluded from host discovery.
Related
- Monitoring nginx and Monitoring Apache, the usual origins behind Varnish
- Monitoring HAProxy
- Monitoring for hosting providers on the main site