Monitor an OpenBSD System

Synopsis #

OpenBSD includes enough base-system tools to establish a useful local monitoring baseline before adding an external platform. This guide inventories resource use, service state, hardware sensors, logs, scheduled maintenance reports, and update status. It also identifies where optional remote telemetry belongs.

Monitoring must produce an actionable signal. Record normal values before setting thresholds, direct root’s local mail to an actively read mailbox, and test each notification path.

Establish a Resource Baseline #

Use systat(1) for interactive views and vmstat(8) for interval samples:

$ systat vmstat
  # Observe CPU, memory, paging, interrupts, and disks
$ vmstat 5 12
  # Record twelve samples at five-second intervals

Inspect filesystems and inodes with df(1) :

$ df -h
  # Display filesystem capacity
$ df -i
  # Display inode consumption

Capacity monitoring must cover both blocks and inodes. A filesystem can reject new files when either resource is exhausted.

Record interface counters, routes, sockets, and PF state:

$ netstat -in
  # Display interface packet and error counters
$ route -n show
  # Display the routing table without DNS lookups
# pfctl -si
  # Display PF status and state counters

Check Services #

rcctl(8) reports failed enabled daemons:

# rcctl ls failed

Check a specific service when its network endpoint or dependent application fails:

# rcctl check sshd
  # Confirm that the daemon process is running
$ netstat -na -f inet
  # Confirm that the expected socket is listening

A running process does not prove that its protocol works. Add an application-level probe from the same network path as its clients.

Inspect Hardware Sensors #

sysctl(8) exposes sensors registered by supported drivers:

$ sysctl hw.sensors

Available sensors vary by platform, firmware, controller, and driver. Absence of a temperature, fan, voltage, drive, or battery sensor is not proof that the underlying hardware lacks that measurement.

sensorsd(8) can monitor selected sensors and run commands when status changes. Start with the example and the current sensorsd.conf(5) manual rather than copying thresholds from another machine:

# test -f /etc/sensorsd.conf || install -o root -g wheel -m 600 /dev/null /etc/sensorsd.conf
  # Create the local configuration only when absent
# vi /etc/sensorsd.conf
  # Add thresholds based on measured normal and documented safe ranges
# rcctl enable sensorsd
  # Enable monitoring at boot
# rcctl start sensorsd
  # Start monitoring now
# rcctl check sensorsd
  # Confirm that the daemon remains running

Test a notification command independently before assigning it to a sensor rule.

Read Daily Security and Maintenance Mail #

daily(8) reports failed daemons, disk status, filesystems due for backup, and security-check output. Root’s mail must reach an account that is actually read.

Review /etc/mail/aliases, preserve existing aliases, and direct root to an administrative mailbox:

root: admin

Rebuild the aliases database and test delivery:

# newaliases
  # Rebuild the aliases database
# printf 'monitoring test\n' | mail -s 'root mail test' root
  # Confirm that root mail reaches the monitored mailbox

Site-specific daily checks belong in /etc/daily.local. Keep them quick, noninteractive, and silent on success. Output becomes part of the daily report.

Review Logs and Rotation #

Use tail(1) for short investigations:

# tail -n 100 /var/log/messages
  # Review recent system messages
# tail -n 100 /var/log/authlog
  # Review authentication events
# tail -n 100 /var/log/daemon
  # Review daemon messages

Do not assume every daemon writes a dedicated file. OpenBSD services commonly log through syslogd(8) . Review /etc/syslog.conf and /etc/newsyslog.conf before changing retention.

Preview log rotation with newsyslog(8) :

# newsyslog -n

The preview must be reviewed before forcing rotation.

Check Update State #

List missing binary errata patches with syspatch(8) :

# syspatch -c

Keep package and firmware maintenance in the normal update workflow. A monitoring probe should report drift; it should not perform unattended upgrades unless that change authority has been designed explicitly.

Add Remote Monitoring Deliberately #

Remote telemetry is useful when local mail cannot report a failed host. Choose the smallest required surface:

  • snmpd(8) exposes base-system metrics to a restricted management network.
  • syslogd(8) can forward selected logs to a collector.
  • pflow(4) exports PF flow records from routers.
  • A remote service probe can test DNS, HTTP, SMTP, SSH, or another application from the client side.

Bind monitoring daemons only to management addresses, restrict sources in both daemon and PF configuration, and verify the collector receives data. Community strings and telemetry can disclose operational details; do not expose them to the Internet.

See Telemetry, Logging, and Flow Export for network-device telemetry and SNMP for the native agent.

Report a bug