Prometheus vs Zabbix vs Nagios: FreeBSD Monitoring Compared

Monitoring is non-negotiable for production FreeBSD servers. The question is which monitoring stack to deploy. Prometheus, Zabbix, and Nagios represent three different philosophies: pull-based metrics with time-series storage, integrated agent-based monitoring, and traditional check-based alerting.

All three run on FreeBSD. Their FreeBSD support quality varies. This guide compares them across architecture, setup complexity, scalability, alerting, visualization, and how well they work with FreeBSD-specific features like ZFS, jails, and pf.

TL;DR -- Quick Verdict

Prometheus + Grafana: Best for modern, metrics-heavy environments. Pull-based model, powerful query language (PromQL), excellent for dynamic infrastructure. Requires separate components (Prometheus, Grafana, Alertmanager, exporters). Best dashboards.

Zabbix: Best all-in-one solution. Agent-based, built-in UI, auto-discovery, templates for everything, trigger-based alerting. Single package to install. Best for traditional infrastructure monitoring with minimal setup.

Nagios (or Icinga 2): Best for check-based monitoring. Plugin ecosystem is massive. Showing its age architecturally. Consider Icinga 2 as a modern Nagios-compatible alternative.

Architecture Comparison

|---|---|---|---|

Prometheus + Grafana

Prometheus is a time-series monitoring system originally built at SoundCloud. It scrapes metrics from targets via HTTP, stores them in a local time-series database, and evaluates alerting rules. Grafana provides the visualization layer.

Installation on FreeBSD

sh
# Install Prometheus
pkg install prometheus

# Install Grafana
pkg install grafana

# Install node_exporter (FreeBSD metrics)
pkg install node_exporter

# Enable services
sysrc prometheus_enable="YES"
sysrc grafana_enable="YES"
sysrc node_exporter_enable="YES"

# Start services
service prometheus start
service grafana start
service node_exporter start

Configuration

Prometheus configuration in /usr/local/etc/prometheus.yml:

sh
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "/usr/local/etc/prometheus/rules/*.yml"

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: "freebsd-servers"
    static_configs:
      - targets:
        - "server1.example.com:9100"
        - "server2.example.com:9100"
        - "server3.example.com:9100"

  - job_name: "nginx"
    static_configs:
      - targets: ["localhost:9113"]

  - job_name: "postgres"
    static_configs:
      - targets: ["localhost:9187"]

Alerting Rules

sh
# /usr/local/etc/prometheus/rules/freebsd.yml
groups:
  - name: freebsd
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"

      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Disk space below 10% on {{ $labels.instance }}"

      - alert: ZPoolDegraded
        expr: node_zfs_zpool_state{state!="online"} > 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "ZFS pool {{ $labels.zpool }} is degraded on {{ $labels.instance }}"

Alertmanager Setup

sh
# Install Alertmanager
pkg install alertmanager

# Enable and start
sysrc alertmanager_enable="YES"
service alertmanager start

Alertmanager configuration (/usr/local/etc/alertmanager/alertmanager.yml):

sh
global:
  smtp_smarthost: "mail.example.com:587"
  smtp_from: "alertmanager@example.com"
  smtp_auth_username: "alertmanager@example.com"
  smtp_auth_password: "password"

route:
  receiver: "email-admin"
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: "email-admin"
    email_configs:
      - to: "admin@example.com"

FreeBSD-Specific Exporters

| Exporter | Package | Metrics |

|---|---|---|

| node_exporter | sysutils/node_exporter | CPU, memory, disk, network, ZFS |

| nginx_exporter | www/nginx-prometheus-exporter | Nginx connections, requests |

| postgres_exporter | databases/postgres_exporter | PostgreSQL stats |

| blackbox_exporter | net-mgmt/blackbox_exporter | HTTP, TCP, ICMP probes |

| mysqld_exporter | databases/mysqld_exporter | MySQL/MariaDB stats |

The node_exporter on FreeBSD includes ZFS metrics out of the box: pool status, ARC hit rates, dataset usage, and scrub status.

Strengths

PromQL is the most powerful monitoring query language available.
Grafana dashboards are unmatched for visualization quality.
Pull-based model works well with dynamic infrastructure.
Federation and Thanos enable massive scale.
Active ecosystem with exporters for everything.

Weaknesses

Multiple components to install and manage (Prometheus, Grafana, Alertmanager, exporters).
No built-in agent -- each target needs an exporter.
No auto-discovery without service discovery configuration.
Steeper learning curve for PromQL.
Log monitoring requires separate tools (Loki).

Zabbix

Zabbix is an integrated monitoring solution that provides data collection, visualization, alerting, and auto-discovery in a single platform. It uses agents on monitored hosts that push data to a central server.

Installation on FreeBSD

sh
# Install Zabbix server with PostgreSQL backend
pkg install zabbix7-server zabbix7-frontend-php83 zabbix7-agent2

# Install and configure PostgreSQL
pkg install postgresql16-server
sysrc postgresql_enable="YES"
service postgresql initdb
service postgresql start

# Create Zabbix database
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix

# Import Zabbix schema
zcat /usr/local/share/zabbix7/server/database/postgresql/schema.sql.gz | \
  sudo -u zabbix psql zabbix
zcat /usr/local/share/zabbix7/server/database/postgresql/images.sql.gz | \
  sudo -u zabbix psql zabbix
zcat /usr/local/share/zabbix7/server/database/postgresql/data.sql.gz | \
  sudo -u zabbix psql zabbix

# Enable services
sysrc zabbix_server_enable="YES"
sysrc zabbix_agent2_enable="YES"

# Start services
service zabbix_server start
service zabbix_agent2 start

Agent Configuration

Zabbix agent2 on monitored FreeBSD servers (/usr/local/etc/zabbix7/zabbix_agent2.conf):

sh
Server=zabbix-server.example.com
ServerActive=zabbix-server.example.com
Hostname=freebsd-host-01

sh
# Install agent on remote FreeBSD servers
pkg install zabbix7-agent2
sysrc zabbix_agent2_enable="YES"
service zabbix_agent2 start

Auto-Discovery

Zabbix can auto-discover hosts on your network and apply templates:

Navigate to Configuration > Discovery in the web UI.
Create a discovery rule for your network range (e.g., 10.0.0.0/24).
Set discovery checks (SNMP, agent, ICMP).
Define actions: auto-add hosts, assign templates, add to groups.

Built-in Templates

Zabbix ships with templates for FreeBSD, including:

FreeBSD by Zabbix agent (CPU, memory, disk, network, processes)
ZFS pool monitoring
Network interface monitoring
Process monitoring

Strengths

All-in-one solution. Single install covers everything.
Built-in web UI with dashboards, maps, and reports.
Auto-discovery reduces manual configuration.
Powerful template system -- share monitoring configurations.
Trigger expressions with dependencies (avoid alert storms).
Historical data storage with configurable retention.
SNMP, IPMI, JMX, and agent monitoring in one platform.

Weaknesses

Agent-based model requires installing agents on all monitored hosts.
Web UI can feel dated compared to Grafana.
Database backend needs tuning for large deployments (>1000 hosts).
Resource-hungry (server + database + web frontend).
Custom metrics require UserParameter scripting.

Nagios

Nagios is the grandfather of open-source monitoring. It invented the plugin-based check model that many tools still use. Nagios Core is the open-source version; Nagios XI is the commercial version with a modern UI.

Installation on FreeBSD

sh
# Install Nagios Core
pkg install nagios4

# Install NRPE for remote checks
pkg install nrpe3

# Install standard plugins
pkg install nagios-plugins

# Enable services
sysrc nagios_enable="YES"

# Configure Apache for Nagios web UI
# Add Nagios config to Apache
service nagios start

Configuration

Nagios uses text configuration files:

sh
# /usr/local/etc/nagios/objects/freebsd-host.cfg
define host {
    use             freebsd-server
    host_name       freebsd-01
    alias           FreeBSD Production Server
    address         10.0.0.10
}

define service {
    use                 generic-service
    host_name           freebsd-01
    service_description CPU Load
    check_command       check_nrpe!check_load
}

define service {
    use                 generic-service
    host_name           freebsd-01
    service_description Disk Usage
    check_command       check_nrpe!check_disk
}

define service {
    use                 generic-service
    host_name           freebsd-01
    service_description ZFS Pool Status
    check_command       check_nrpe!check_zpool
}

NRPE configuration on monitored host (/usr/local/etc/nrpe.cfg):

sh
allowed_hosts=zabbix-server.example.com
command[check_load]=/usr/local/libexec/nagios/check_load -w 5,4,3 -c 10,8,6
command[check_disk]=/usr/local/libexec/nagios/check_disk -w 20% -c 10% -p /
command[check_zpool]=/usr/local/libexec/nagios/check_zpool.sh

Consider Icinga 2 Instead

Icinga 2 is a Nagios-compatible rewrite with modern architecture, a REST API, built-in cluster support, and the Icinga Web 2 interface. It uses Nagios plugins but adds:

Distributed monitoring with zones and endpoints
REST API for automation
Modern web UI (Icinga Web 2)
DSL-based configuration
Built-in HA

sh
# Install Icinga 2 on FreeBSD
pkg install icinga2 icingaweb2

Strengths

Massive plugin ecosystem (thousands of check plugins).
Simple concept: run a check, get a return code (OK/WARNING/CRITICAL/UNKNOWN).
Well-understood by operations teams worldwide.
Lightweight core process.
Icinga 2 addresses most Nagios Core limitations.

Weaknesses

Outdated architecture (Nagios Core).
No built-in metrics storage or graphing (needs PNP4Nagios, Graphite, etc.).
Text file configuration is tedious at scale.
No native REST API (Nagios Core).
Web UI is spartan (Nagios Core).
Scaling requires complex distributed setups.

Feature Comparison

|---|---|---|---|---|

FreeBSD-Specific Monitoring

ZFS Monitoring

|---|---|---|---|

Prometheus with node_exporter provides the most comprehensive ZFS metrics out of the box.

Jail Monitoring

Monitor individual jails by running an exporter or agent inside each jail:

sh
# Prometheus: run node_exporter in each jail
# In the jail's rc.conf
sysrc node_exporter_enable="YES"
sysrc node_exporter_args="--web.listen-address=:9100"

# Zabbix: run zabbix_agent2 in each jail
pkg install zabbix7-agent2
sysrc zabbix_agent2_enable="YES"

pf Firewall Metrics

sh
# Prometheus: use a custom script or textfile collector
# Collect pf stats for node_exporter textfile collector
pfctl -si | awk '/Evaluations/{print "pf_evaluations "$2}' \
  > /var/tmp/node_exporter/pf.prom

# Zabbix: UserParameter
# /usr/local/etc/zabbix7/zabbix_agent2.d/pf.conf
UserParameter=pf.states,pfctl -si | grep current | awk '{print $3}'
UserParameter=pf.evaluations,pfctl -si | grep evaluations | awk '{print $4}'

Choosing the Right Tool

Choose Prometheus + Grafana if:

You want the best dashboards and visualization.
Your infrastructure is dynamic (containers, cloud instances).
You need a powerful query language for complex metrics analysis.
You are comfortable managing multiple components.
You want to integrate with modern alerting (PagerDuty, Slack, OpsGenie).

Choose Zabbix if:

You want a single integrated platform.
You prefer web-based configuration over text files.
You need auto-discovery of hosts and services.
You monitor traditional infrastructure (physical servers, network equipment, VMs).
You want low operational overhead after initial setup.

Choose Nagios/Icinga 2 if:

You have existing Nagios plugins and configurations.
You need check-based monitoring (UP/DOWN, service status).
Your team already knows Nagios.
Go with Icinga 2 for a modernized Nagios-compatible experience.

FAQ

Which monitoring tool has the best FreeBSD support?

Prometheus with node_exporter has the most comprehensive FreeBSD metrics out of the box, especially for ZFS. Zabbix has good FreeBSD templates. Nagios plugins work on FreeBSD but may need customization.

Can I run Prometheus and Zabbix together?

Yes. Some organizations use Prometheus for metrics and Grafana dashboards while keeping Zabbix for availability monitoring and alerting. Grafana can even query Zabbix as a data source. However, running both adds complexity -- pick one as your primary.

How do I monitor ZFS on FreeBSD?

Prometheus node_exporter exposes ZFS metrics automatically (pool status, ARC statistics, dataset usage). For Zabbix, use the built-in FreeBSD template or create UserParameters that parse zpool status and zfs list output. For Nagios, use the check_zpool plugin.

What is the lightest monitoring option for a single FreeBSD server?

If you only need to monitor one server, Prometheus + Grafana is overkill. Use monit (sysutils/monit) for simple process and resource monitoring with email alerts. It uses minimal resources and requires minimal configuration.

sh
pkg install monit
sysrc monit_enable="YES"

How much disk space does each monitoring tool need?

Prometheus: approximately 1-2 bytes per sample. At 15-second scrape intervals with 1000 time series, that is about 250 MB/month. Zabbix: depends on the number of items and retention; a 1000-host setup with 1 year retention needs 50-200 GB in the database. Nagios: minimal (check results are not stored long-term unless using PNP4Nagios or similar).

Should I use Nagios or Icinga 2 on FreeBSD?

Icinga 2. It is Nagios-compatible (uses the same plugins) but has a modern architecture, REST API, distributed monitoring, and a much better web UI. There is no compelling reason to deploy Nagios Core over Icinga 2 for new installations.