Building systems that are always available: failover with CARP (Common Address Redundancy Protocol), the carpdev concept, and load balancing. You will also set up monitoring with sysstat, netdata, Prometheus and node_exporter, and manage logs with newsyslog and /etc/newsyslog.conf.

In the previous episode 19, you ran FreeBSD as a router and application server. Now we go to the next level: high availability and monitoring — the system's ability to keep running when something fails, and your ability to see it before it fails.
A single reliable server still has a single point of failure. With CARP, two FreeBSD servers can share the same IP address and automatically take over when the primary dies. And with good monitoring, you know about problems before users feel them. Let's build both.
CARP (Common Address Redundancy Protocol) is a failover protocol that lets multiple hosts share a virtual IP address. If the primary host dies, the backup host takes over that address within seconds — clients don't notice any disruption.
CARP is a kernel module:
kldload carp
sysrc if_carp_load="YES"Configuration is done by creating a carp0 interface on both servers. On the master server:
sysrc cloned_interfaces="carp0"
sysrc ifconfig_carp0="vhid 1 pass secret123 192.168.1.254/24"On the backup server, add carpdev and a lower priority:
sysrc ifconfig_carp0="vhid 1 advskew 100 pass secret123 192.168.1.254/24 carpdev em1"Warning
Both servers must use the same vhid and the same pass. advskew determines priority — a smaller value means it's more "preferred" to be master. Never use an easily guessable CARP password.
To test, bring the master interface down and watch whether the backup takes over:
ifconfig carp0
ifconfig carp0 down
ifconfig carp0 upifconfig carp0 shows MASTER or BACKUP status. When the master dies, the backup automatically rises to MASTER and holds the virtual IP address.
The CARP virtual IP can be used for any service — from a gateway router to a reverse proxy. The combination of CARP + an active service (like Nginx or pf) means clients always have a live target.
Success
CARP is the foundation of high availability on FreeBSD. With CARP for IP failover, pf for state sync between firewalls, and ZFS for data, you have a triplet that lets systems survive hardware failures.
Besides failover, CARP can be combined with load balancing: several active servers share traffic. At the application layer, Nginx can act as a load balancer:
upstream backend {
server 192.168.1.10;
server 192.168.1.11;
}For the network layer, pf can also split connections (episode 12). Choose the layer according to your needs and complexity.
sysstat runs scheduled monitoring with cron and stores history:
pkg install sysstatOnce enabled via cron, you can read the statistics history with vmstat and systat based on the collected data.
netdata gives a rich real-time dashboard without complex configuration:
pkg install netdata
sysrc netdata_enable="YES"
service netdata startNetdata displays system, network, and application metrics through a web browser — the fastest way to visualize a machine's condition.
For monitoring that can be collected and stored long term, install Prometheus and node_exporter:
pkg install prometheus node_exporter
sysrc node_exporter_enable="YES"
service node_exporter startnode_exporter exposes metrics on port 9100, and Prometheus collects them periodically:
curl -s http://127.0.0.1:9100/metrics | headInfo
The recommended pattern: node_exporter on every machine exposes metrics, Prometheus collects and stores them, then Grafana visualizes. This is the standard industry monitoring architecture that runs well on FreeBSD.
newsyslog rotates log files so they don't grow without limit. Configuration lives in /etc/newsyslog.conf:
cat /etc/newsyslog.confExample entries: maximum size, number of old files, and compression mode.
Add rotation for your own application logs:
/var/log/app.log 644 7 100 * JThe entry above: mode 644, keep 7 files, rotate when reaching 100 KB, no delay.
Warning
Logs that aren't rotated will fill the disk and can stop services. Make sure every application that writes logs has a newsyslog entry — a full disk is the most commonly overlooked cause of failure.
Run a manual rotation for testing:
newsyslog
ls -la /var/log | headOne machine can collect everything: node_exporter for metrics, sysstat for history, newsyslog for log rotation, and netdata for a quick dashboard:
service node_exporter status
service netdata status
newsyslog -vIn this episode 20, you built high availability with CARP, understood the carpdev concept and load balancing, set up monitoring with sysstat, netdata, Prometheus and node_exporter, and managed logs with newsyslog.
Key takeaways: