Skip to main content

Monitoring HAProxy

HAProxy is recognised by its process and read through the stats socket it already has. No stats page to expose, no exporter, no configuration change beyond a stats socket line that most installations carry anyway. Every frontend, backend and server shows up in the console with its health and traffic within a minute.

How HAProxy is recognised​

The haproxy definition matches a running process named haproxy. Every 60 seconds the agent reads /etc/haproxy/haproxy.cfg for two facts, the stats socket path and the global maxconn, then connects to that socket and issues show info and show stat, with a 10-second budget. When the configuration names no socket, the agent tries /run/haproxy/admin.sock and then /var/run/haproxy.sock. The version comes from show info. A companion logs-haproxy definition follows the haproxy identifier in the journal every 30 seconds.

What is collected​

The process. Current connections, connection rate and uptime as HAProxy reports them.

Frontends, backends, servers. Each row of show stat becomes a set of metrics tagged with the proxy name and its kind. A frontend reports its current and total sessions and the 5xx it answered. A backend adds a health flag, connection errors towards its servers and the number of active servers. Each real server reports its own health, sessions and 5xx. Health is 1 when HAProxy's status starts with UP, is OPEN, or the row has no check configured. On top, the agent counts backends and servers up versus configured, so one number tells you how much of the pool is alive.

Facts shown on the host page: version, the stats socket in use and the global maxconn.

SignalMetric
Current connections, connection rate, uptimesvc.haproxy.current_connections, .conn_rate, .uptime
Backends and servers up versus configuredsvc.haproxy.backends_up / .backends_total, .servers_up / .servers_total
Backend healthsvc.haproxy.proxy.up tagged proxy, kind
Sessions per frontend or backendsvc.haproxy.proxy.sessions, .proxy.sessions_total
5xx and connection errors through a proxysvc.haproxy.proxy.hrsp_5xx_total, .proxy.conn_errors_total
Active servers in a backendsvc.haproxy.proxy.active_servers
Per-server health, sessions, 5xxsvc.haproxy.server.up, .server.sessions, .server.hrsp_5xx_total tagged proxy, server

Names, tags and units are in the metrics reference.

Logs. HAProxy's journal entries ship by default at notice level and above; lines it emits at info level, the per-request log among them, are collected only when you switch the service to full depth in the console.

Alerts out of the box​

RuleFires whenSeverityShips
HAProxy backend is downa backend's health reads 0 for 2 minuteswarningon
Service floods error logs50 or more error lines in 15 minuteswarningauto

The rule watches the backend row, not the servers: HAProxy marks a backend down only when none of its servers can take traffic, so one server failing its health check in a pool of three never raises it, while a pool with nothing left behind it does. Two minutes covers the restart of a backend's single server without waking anyone, and the incident closes as soon as the backend reads up again. The rule opens one incident per backend name. Thresholds and hysteresis are in the rules catalog.

Limitations​

  • The probe needs a stats socket. Without a stats socket line and without a socket at either default path, the check fails and says so; the process is still tracked by the host-level discovery.
  • Only the first stats socket line of /etc/haproxy/haproxy.cfg is read. A socket declared in an included file is found only if it sits at one of the two default paths.
  • Session totals, 5xx and connection errors are cumulative counters; the console shows them as HAProxy reports them, no per-minute rate is derived.
  • Queue lengths, response times and server weights are not collected.
  • A frontend has no health flag of its own; the shipped rule covers backends.
  • An HAProxy running inside a container is not matched by this definition, because containers are excluded from host discovery.