Synopsis #
Start with OpenBSD’s base tools for local monitoring before adding an external platform. This guide covers resource use, services, hardware sensors, logs, scheduled reports, updates, and optional remote monitoring.
Monitoring should make failures visible to someone who can respond. 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
doas pfctl -si
# Display PF status and state counters
Check Services #
rcctl(8) reports failed enabled daemons:
doas rcctl ls failed
Check a specific service when its network endpoint or dependent application fails:
doas 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:
doas test -f /etc/sensorsd.conf || doas install -o root -g wheel -m 600 /dev/null /etc/sensorsd.conf
# Create the local configuration only when absent
doas vi /etc/sensorsd.conf
# Add thresholds based on measured normal and documented safe ranges
doas rcctl enable sensorsd
# Enable monitoring at boot
doas rcctl start sensorsd
# Start monitoring now
doas 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:
doas 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:
doas tail -n 100 /var/log/messages
# Review recent system messages
doas tail -n 100 /var/log/authlog
# Review authentication events
doas 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) :
doas newsyslog -n
The preview must be reviewed before forcing rotation.
Check Update State #
List missing binary errata patches with syspatch(8) :
doas syspatch -c
Keep package and firmware maintenance in the normal update workflow. Keep monitoring checks separate from update jobs so an alert does not also change the system.
Add Remote Monitoring #
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.