Skip to main content

Monitoring keepalived

keepalived is recognised by its process, and the question that matters on a VRRP pair, "which node holds the address right now", is answered from facts rather than from what the configuration hopes. The agent reads the virtual addresses out of keepalived.conf and checks whether they sit on this node's interfaces. Nothing is sent to keepalived and nothing in its configuration is changed.

How keepalived is recognised​

The keepalived definition matches a running process named keepalived. Every 30 seconds a compiled probe reads /etc/keepalived/keepalived.conf, takes the addresses of the first virtual_ipaddress block together with the configured priority, state and virtual_router_id, and compares the addresses with the ones assigned to the host's interfaces. A companion logs-keepalived definition follows the Keepalived, Keepalived_vrrp and keepalived identifiers in the journal every 30 seconds. If the configuration file cannot be read, the check fails and says why.

What is collected​

Who holds the address. The de-facto role: active is 1 only when every configured virtual address is present on a local interface, and vips_held counts how many of them are. Run this on both nodes of a pair and the picture is unambiguous: one node at 1, the other at 0, and a failover shows up as the two flipping within a probe cycle. Two nodes at 1 at the same time is the split brain you want to know about.

Configuration. The VRRP priority as a metric, so a chart of the pair shows who is supposed to win an election; the configured state (MASTER or BACKUP), the virtual_router_id and the list of virtual addresses as facts on the host page.

SignalMetric
This node holds every configured virtual addresssvc.keepalived.active
How many of the configured virtual addresses this node holdssvc.keepalived.vips_held
Configured VRRP prioritysvc.keepalived.priority

Names, tags and units are in the metrics reference.

Logs. keepalived's journal entries ship by default at notice level and above; what it logs at info level is collected only when you switch the service to full depth in the console. See Logs.

Alerts out of the box​

No alert rule ships for keepalived's metrics. Which node should be master depends on your pair, and a rule that fires on "the backup is not active" would be wrong on the backup by design, so the platform leaves that decision to you. Any of the three metrics above can drive a custom rule in the console: svc.keepalived.active == 0 on the node that is meant to hold the address, or svc.keepalived.vips_held below the number of addresses you configured. See alert rules and the rules catalog. The shared rule "monitoring cannot collect from a service" still covers a keepalived whose configuration became unreadable.

Limitations​

  • Only the first virtual_ipaddress block is read, so a configuration with several vrrp_instance sections is judged by its first instance.
  • Only IPv4 virtual addresses are recognised.
  • The role is derived from interface addresses, not from VRRP itself. Advertisement timing, preemption and the health of the peer are not observed; a virtual address left on both nodes after a split brain reads as active on both, which is exactly what the metric should show.
  • The configured state is what the file says, not the live state; the live answer is active.
  • The configuration is read from /etc/keepalived/keepalived.conf; include directives are not followed.
  • A keepalived running inside a container is not matched by this definition, because containers are excluded from host discovery.