Nagios on FreeBSD: Still Relevant in 2026?
Nagios is the monitoring tool that defined infrastructure monitoring for a generation. Released in 1999 as "NetSaint" and renamed to Nagios in 2002, it established the paradigm of host and service checks with green/yellow/red status indicators that every subsequent monitoring tool has either adopted or reacted against. At its peak, Nagios was the default choice for any organization that needed to know when a server was down or a service was degraded.
In 2026, the monitoring landscape looks very different. Prometheus dominates cloud-native monitoring. Zabbix offers a more complete enterprise platform. Netdata provides instant real-time visibility. Yet Nagios continues to run in thousands of production environments, and the FreeBSD ports tree still maintains current packages. This review examines what Nagios does well on FreeBSD today, where it falls short, and when you should migrate to something else.
For a side-by-side comparison of all major monitoring tools, see the monitoring tools comparison.
What Nagios Still Does Well
Before listing Nagios's weaknesses -- and there are many compared to modern tools -- it is worth understanding why it persists.
Simplicity of concept. Nagios checks are scripts that exit with a return code: 0 (OK), 1 (WARNING), 2 (CRITICAL), 3 (UNKNOWN). Any script in any language that follows this convention is a Nagios plugin. This is the simplest possible monitoring interface. You can write a check for anything in five minutes.
Plugin ecosystem. Decades of community plugins exist on the Nagios Exchange and GitHub. Checks for obscure hardware, proprietary protocols, legacy applications, and niche services that no other monitoring tool covers. If something can be checked with a script, someone has probably written a Nagios plugin for it.
Lightweight agent-less monitoring. Nagios does not require agents on monitored hosts. It can monitor entirely through SNMP, SSH, ICMP, and TCP/UDP checks from the central server. This matters in environments where you cannot install agents on every device -- network equipment, printers, embedded systems, appliances.
Battle-tested alerting. Nagios's notification system is straightforward. When a check changes state, it sends a notification via the configured method (email, SMS, script). Contact groups, escalation, and notification periods work reliably. There are no surprises.
Low resource usage. The Nagios Core daemon uses minimal CPU and memory. A Nagios server monitoring 500 hosts with 2,000 service checks consumes less than 200 MB of RAM and negligible CPU between check intervals.
Installation on FreeBSD
Nagios Core from Packages
shpkg install nagios4 nagios-plugins
This installs Nagios Core 4.x and the standard plugin collection. Configuration files live under /usr/local/etc/nagios/. The web interface files are installed to /usr/local/www/nagios/.
Enable Nagios:
shsysrc nagios_enable="YES"
Web Interface Setup
Nagios's web interface requires a web server with CGI support. NGINX does not support CGI natively, so Apache is the traditional choice:
shpkg install apache24 mod_php83 sysrc apache24_enable="YES"
Configure Apache for Nagios CGI:
shcat > /usr/local/etc/apache24/Includes/nagios.conf << 'EOF' ScriptAlias /nagios/cgi-bin "/usr/local/www/nagios/cgi-bin" Alias /nagios "/usr/local/www/nagios" <Directory "/usr/local/www/nagios"> Options None AllowOverride None Require all granted </Directory> <Directory "/usr/local/www/nagios/cgi-bin"> Options ExecCGI AllowOverride None AddHandler cgi-script .cgi Require all granted </Directory> EOF
Create the Nagios web user:
shhtpasswd -c /usr/local/etc/nagios/htpasswd.users nagiosadmin
Start Apache:
shservice apache24 start
Verify and Start
Validate the configuration:
shnagios -v /usr/local/etc/nagios/nagios.cfg
Start Nagios:
shservice nagios start
Access the web interface at http://your-server/nagios/.
Configuration: The Pain Point
Nagios's configuration model is its greatest weakness. Everything is defined in flat text files with a custom object definition syntax. Here is a minimal host and service definition:
sh# /usr/local/etc/nagios/objects/webserver.cfg define host { use freebsd-server host_name web01 alias Web Server 01 address 10.0.0.11 max_check_attempts 5 check_period 24x7 notification_interval 30 notification_period 24x7 contacts admin } define service { use generic-service host_name web01 service_description HTTP check_command check_http check_interval 5 retry_interval 1 max_check_attempts 3 notification_interval 30 } define service { use generic-service host_name web01 service_description SSH check_command check_ssh check_interval 5 retry_interval 1 max_check_attempts 3 } define service { use generic-service host_name web01 service_description Disk Usage check_command check_nrpe!check_disk check_interval 15 retry_interval 5 max_check_attempts 3 }
This is one host with three services. Now imagine 200 hosts, each with 10-20 services. The configuration becomes thousands of lines of repetitive object definitions. Template inheritance (use) reduces some duplication, but the fundamental problem remains: Nagios's configuration does not scale to large environments without external tooling.
NRPE for Remote Checks
To execute plugins on remote hosts, install NRPE (Nagios Remote Plugin Executor):
On the monitored host:
shpkg install nrpe3 nagios-plugins sysrc nrpe3_enable="YES"
Configure NRPE:
sh# /usr/local/etc/nrpe.cfg server_address=0.0.0.0 allowed_hosts=10.0.0.1 dont_blame_nrpe=0 command[check_disk]=/usr/local/libexec/nagios/check_disk -w 20% -c 10% -p / command[check_load]=/usr/local/libexec/nagios/check_load -w 5,4,3 -c 10,8,6 command[check_procs]=/usr/local/libexec/nagios/check_procs -w 250 -c 400 command[check_swap]=/usr/local/libexec/nagios/check_swap -w 40% -c 20% command[check_mem]=/usr/local/libexec/nagios/check_mem -w 80 -c 90
Start NRPE:
shservice nrpe3 start
On the Nagios server, define the NRPE check command:
sh# /usr/local/etc/nagios/objects/commands.cfg define command { command_name check_nrpe command_line /usr/local/libexec/nagios/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }
FreeBSD-Specific Checks
Standard plugins that work well on FreeBSD:
sh# Check ZFS pool health /usr/local/libexec/nagios/check_zpool -p zroot -w 80 -c 90 # Check ZFS ARC hit rate (custom script) cat > /usr/local/libexec/nagios/check_zfs_arc << 'SCRIPT' #!/bin/sh HITS=$(sysctl -n kstat.zfs.misc.arcstats.hits) MISSES=$(sysctl -n kstat.zfs.misc.arcstats.misses) TOTAL=$((HITS + MISSES)) if [ "$TOTAL" -eq 0 ]; then echo "OK - No ARC activity" exit 0 fi RATIO=$(echo "scale=1; $HITS * 100 / $TOTAL" | bc) if [ $(echo "$RATIO < 80" | bc) -eq 1 ]; then echo "CRITICAL - ARC hit ratio ${RATIO}%|arc_hit_ratio=${RATIO}%" exit 2 elif [ $(echo "$RATIO < 90" | bc) -eq 1 ]; then echo "WARNING - ARC hit ratio ${RATIO}%|arc_hit_ratio=${RATIO}%" exit 1 else echo "OK - ARC hit ratio ${RATIO}%|arc_hit_ratio=${RATIO}%" exit 0 fi SCRIPT chmod +x /usr/local/libexec/nagios/check_zfs_arc
sh# Check PF state table usage cat > /usr/local/libexec/nagios/check_pf_states << 'SCRIPT' #!/bin/sh STATES=$(pfctl -si 2>/dev/null | grep "current entries" | awk '{print $3}') LIMIT=$(pfctl -sm 2>/dev/null | grep states | awk '{print $4}') if [ -z "$STATES" ] || [ -z "$LIMIT" ]; then echo "UNKNOWN - Cannot read PF state table" exit 3 fi PCT=$((STATES * 100 / LIMIT)) if [ "$PCT" -gt 90 ]; then echo "CRITICAL - PF states: $STATES/$LIMIT (${PCT}%)|pf_states=$STATES" exit 2 elif [ "$PCT" -gt 75 ]; then echo "WARNING - PF states: $STATES/$LIMIT (${PCT}%)|pf_states=$STATES" exit 1 else echo "OK - PF states: $STATES/$LIMIT (${PCT}%)|pf_states=$STATES" exit 0 fi SCRIPT chmod +x /usr/local/libexec/nagios/check_pf_states
What Nagios Does Poorly in 2026
No built-in metrics storage. Nagios checks return a status and optional performance data, but Nagios Core has no time-series database. Performance data must be piped to external tools (PNP4Nagios, Graphite, InfluxDB) for graphing. This was acceptable in 2005. In 2026, every competitor includes integrated metrics and visualization.
No auto-discovery. You must manually define every host and service. Zabbix discovers hosts and services automatically. Prometheus discovers targets through service discovery. Nagios requires you to know what exists and configure it explicitly.
Web interface is frozen in 2005. The Nagios Core web interface is a CGI-based application that has not been meaningfully updated in over a decade. No interactive graphs, no drag-and-drop, no responsive design, no API-driven dashboards. Nagios XI (commercial) has a modern interface, but Core's is genuinely painful to use for daily operations.
Configuration management nightmare. Object-definition files with inheritance work for 50 hosts. At 500 hosts, you need a configuration management tool (Ansible, Puppet) generating Nagios configs from templates. At 2,000 hosts, you need to question whether the tool that requires this much external scaffolding is the right choice.
No native API. Nagios Core has no REST API. External commands are submitted through a named pipe (/var/spool/nagios/cmd/nagios.cmd). Status data is read from status.dat or the CGI interface. Modern integrations expect APIs.
Plugin quality varies wildly. The Nagios Exchange has thousands of plugins, but quality ranges from production-grade to abandoned Perl scripts from 2008. There is no curation, versioning, or testing framework.
When Nagios Is Still the Right Choice
Despite its weaknesses, Nagios remains appropriate in specific scenarios:
- Existing Nagios infrastructure that works. If you have a tuned Nagios setup monitoring hundreds of hosts with custom plugins and the team knows it well, migrating purely for the sake of modernity is not justified. Migrate when there is a concrete operational need.
- Agent-less monitoring of legacy equipment. If you need to monitor devices where you cannot install agents and the checks are simple (ICMP ping, TCP port, SNMP OID, HTTP status), Nagios does this with minimal overhead and complexity.
- Simple status checks, not metrics. If you only care about "is it up or down" and do not need time-series data, dashboards, or trend analysis, Nagios's model is perfectly adequate.
- Air-gapped or minimal environments. Nagios Core has no external dependencies beyond a C compiler and a web server. No database server, no message queue, no container runtime. It can run on hardware where Zabbix or Prometheus would be impractical.
When to Migrate Away
Migrate from Nagios if:
- You need metrics visualization and capacity planning (choose Prometheus + Grafana)
- You need auto-discovery for dynamic infrastructure (choose Zabbix or Prometheus)
- You need a modern web interface for daily operations (choose Zabbix or Netdata)
- You are spending more time managing Nagios config files than managing the infrastructure they monitor (choose anything else)
- You need API-driven monitoring for CI/CD integration (choose Prometheus)
Migration Path to Zabbix
Zabbix can execute Nagios plugins via UserParameters or system.run[]. This allows incremental migration:
- Deploy Zabbix alongside Nagios
- Import Nagios host inventory into Zabbix
- Create UserParameters that call existing Nagios plugins
- Gradually replace plugin-based checks with native Zabbix items
- Decommission Nagios when all checks are migrated
Migration Path to Prometheus
Prometheus operates on a fundamentally different model (pull-based metrics vs status checks). Migration is a replacement, not a conversion:
- Deploy Prometheus and node_exporter on all hosts
- Recreate Nagios check logic as Prometheus alerting rules
- Build Grafana dashboards to replace Nagios status views
- Run both systems in parallel until confidence is established
- Decommission Nagios
Nagios Core vs Nagios XI
Nagios XI is the commercial product from Nagios Enterprises. It adds:
- Modern web interface with dashboards and wizards
- Configuration management through the web interface
- Auto-discovery (limited)
- Performance graphing built in
- REST API
- Role-based access control
- Reporting and capacity planning
- Commercial support
Nagios XI is proprietary and licensed per-server. On FreeBSD, it is officially supported on CentOS/RHEL only -- running it on FreeBSD requires unsupported modifications. If you want commercial monitoring on FreeBSD, Zabbix (fully open-source) or Datadog (SaaS) are better choices than trying to run Nagios XI on an unsupported platform.
Performance on FreeBSD
Nagios Core is impressively lightweight:
- 500 hosts, 2,000 services, 5-minute check interval: 50-100 MB RAM, negligible CPU
- 2,000 hosts, 10,000 services, 3-minute check interval: 200-400 MB RAM, 10-15% CPU on a single core
- 5,000 hosts, 25,000 services: possible but requires careful tuning of check intervals, result reaper frequency, and process limits
The check execution model is fork-based: Nagios forks a child process for each check. On FreeBSD, fork() is fast, but at high check rates this becomes the bottleneck. For large installations, use NRPE for remote checks (one fork per check) rather than SSH-based checks (two forks per check plus SSH overhead).
Tune the check execution:
sh# /usr/local/etc/nagios/nagios.cfg max_concurrent_checks=200 check_result_reaper_frequency=5 max_check_result_reaper_time=30 cached_host_check_horizon=15 cached_service_check_horizon=15
Real-World FreeBSD Configuration Example
Here is a more complete configuration for monitoring a small FreeBSD infrastructure:
sh# /usr/local/etc/nagios/objects/freebsd-templates.cfg define host { name freebsd-server use generic-host check_period 24x7 check_interval 5 retry_interval 1 max_check_attempts 5 check_command check-host-alive notification_period 24x7 notification_interval 60 notification_options d,u,r contact_groups sysadmins register 0 } define service { name freebsd-service use generic-service check_period 24x7 check_interval 5 retry_interval 1 max_check_attempts 3 notification_period 24x7 notification_interval 60 notification_options w,u,c,r contact_groups sysadmins register 0 }
sh# /usr/local/etc/nagios/objects/hostgroups.cfg define hostgroup { hostgroup_name freebsd-servers alias FreeBSD Servers } define hostgroup { hostgroup_name web-servers alias Web Servers } define hostgroup { hostgroup_name db-servers alias Database Servers }
FAQ
Q: Can I run Nagios inside a FreeBSD jail?
A: Yes. Nagios Core runs well in a jail. Install Apache or another CGI-capable web server in the same jail for the web interface. Ensure the jail can reach all monitored hosts on the required ports.
Q: Does Nagios work with PF on FreeBSD?
A: Yes. Nagios monitors PF through custom plugins that parse pfctl output. Install the check scripts on the Nagios server or use NRPE to execute them on the firewall host.
Q: How do I graph Nagios performance data on FreeBSD?
A: Install PNP4Nagios (pkg install pnp4nagios) or pipe performance data to InfluxDB/Graphite. PNP4Nagios is the traditional choice and integrates directly with the Nagios web interface.
Q: Is Nagios open-source?
A: Nagios Core is open-source under the GPL. Nagios XI, the commercial product, is proprietary. Nagios plugins are open-source. All references in this review are to Nagios Core unless noted otherwise.
Q: Can Nagios plugins be used with other monitoring tools?
A: Yes. Zabbix can execute Nagios plugins via UserParameters. Prometheus has the nagios_exporter for running check plugins. Icinga 2 (a Nagios fork) uses the same plugin format natively.
Q: Should I use Nagios or Icinga 2?
A: If you like the Nagios plugin model but want modern features (REST API, distributed monitoring, better configuration syntax, real-time graphs), use Icinga 2. It is API-driven, has a modern web interface (Icinga Web 2), supports the same plugin format, and runs on FreeBSD. It is effectively what Nagios Core should have become.
Q: What is the best Nagios alternative for FreeBSD?
A: Zabbix for enterprise monitoring with SNMP and auto-discovery. Prometheus + Grafana for cloud-native and container environments. Netdata for instant single-server visibility. See the monitoring tools comparison for details.
For a comprehensive monitoring strategy, see the FreeBSD server monitoring guide.