Zabbix on FreeBSD: Enterprise Monitoring Review
Zabbix is an enterprise-grade monitoring platform that has been in active development since 2001. It monitors servers, network devices, cloud instances, databases, applications, and services through agents, SNMP, IPMI, JMX, and HTTP checks. Where lighter tools like Netdata focus on real-time per-host visibility, and Prometheus focuses on time-series collection and alerting, Zabbix provides the full enterprise monitoring stack: data collection, visualization, alerting, escalation, auto-discovery, network mapping, SLA reporting, and configuration management -- all in a single integrated platform.
FreeBSD is a first-class platform for Zabbix. Both the server and agent components are available as binary packages, and Zabbix has a long history of running reliably on FreeBSD in production. This review covers installation, template configuration, SNMP monitoring, auto-discovery, performance at scale, and how Zabbix compares to Prometheus and Nagios.
For a broader view of monitoring options, see the monitoring tools comparison.
Zabbix Architecture Overview
Zabbix consists of several components:
- Zabbix Server: the central process that receives data from agents and SNMP, processes triggers, sends alerts, and stores data in a database (PostgreSQL or MySQL).
- Zabbix Agent (or Agent 2): installed on monitored hosts, collects local system metrics and sends them to the server. Agent 2 is the newer Go-based agent with plugin support.
- Zabbix Frontend: a PHP web application that provides the dashboard, configuration interface, and reporting. Runs on NGINX or Apache with PHP-FPM.
- Zabbix Proxy (optional): a lightweight data collector for remote sites. Collects data locally and forwards it to the central server, reducing bandwidth and providing buffering for unreliable links.
- Database: PostgreSQL or MySQL/MariaDB stores configuration, historical data, and trends.
All components run well on FreeBSD. For small to medium deployments (up to 1,000 hosts), you can run everything on a single FreeBSD server. For larger deployments, separate the database and web frontend onto dedicated machines.
Installation on FreeBSD
Zabbix Server with PostgreSQL
Install the server, frontend, and database:
shpkg install zabbix7-server zabbix7-frontend-php83 zabbix7-agent2 pkg install postgresql16-server nginx php83 php83-pgsql php83-gd php83-bcmath php83-mbstring php83-xml php83-ldap php83-sockets php83-gettext
Initialize and start PostgreSQL:
shsysrc postgresql_enable="YES" service postgresql initdb service postgresql start
Create the Zabbix database and user:
shsu - postgres -c "createuser --pwprompt zabbix" su - postgres -c "createdb -O zabbix -E Unicode -T template0 zabbix"
Import the Zabbix schema:
shcd /usr/local/share/zabbix7/server/database/postgresql cat schema.sql | su - postgres -c "psql -U zabbix zabbix" cat images.sql | su - postgres -c "psql -U zabbix zabbix" cat data.sql | su - postgres -c "psql -U zabbix zabbix"
Configure the Zabbix server:
sh# /usr/local/etc/zabbix7/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=your_secure_password DBPort=5432 StartPollers=10 StartPingers=5 CacheSize=256M HistoryCacheSize=64M TrendCacheSize=32M ValueCacheSize=128M
Enable and start the server:
shsysrc zabbix_server_enable="YES" service zabbix_server start
Zabbix Agent 2
Agent 2 is the modern Go-based agent. Install on every monitored FreeBSD host:
shpkg install zabbix7-agent2
Configure the agent:
sh# /usr/local/etc/zabbix7/zabbix_agent2.conf Server=10.0.0.1 ServerActive=10.0.0.1 Hostname=webserver01.example.com ListenPort=10050
Enable and start:
shsysrc zabbix_agent2_enable="YES" service zabbix_agent2 start
Verify connectivity from the server:
shzabbix_get -s webserver01.example.com -k system.hostname
This should return the hostname of the monitored host.
Web Frontend Setup
Configure NGINX with PHP-FPM for the Zabbix frontend:
sh# /usr/local/etc/nginx/nginx.conf server { listen 80; server_name zabbix.example.com; root /usr/local/www/zabbix7; index index.php; location / { try_files $uri $uri/ =404; } location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }
Configure PHP for Zabbix requirements:
sh# /usr/local/etc/php.ini max_execution_time = 300 memory_limit = 256M post_max_size = 16M upload_max_filesize = 2M max_input_time = 300 date.timezone = UTC
Enable and start NGINX and PHP-FPM:
shsysrc nginx_enable="YES" sysrc php_fpm_enable="YES" service php-fpm start service nginx start
Open http://zabbix.example.com and complete the web-based setup wizard. Default login is Admin / zabbix -- change this immediately.
Template Configuration for FreeBSD
Zabbix uses templates to define what data to collect from hosts. Templates contain items (metrics), triggers (alert conditions), graphs, and discovery rules.
Built-in FreeBSD Template
Zabbix ships with a FreeBSD by Zabbix agent template that monitors:
- CPU utilization, load average, context switches
- Memory usage (wired, active, inactive, free, buffers, cached)
- Swap usage and I/O
- Filesystem usage per mount point
- Network interface traffic, errors, and drops
- Process count by state
- System uptime and boot time
Apply the template to a host through the web interface: Configuration > Hosts > your-host > Templates > Link new templates > FreeBSD by Zabbix agent.
ZFS Monitoring Template
The built-in FreeBSD template does not cover ZFS-specific metrics. Create a custom template for ZFS monitoring with these items:
shell# Key: vfs.fs.size[/zpool-name,total] # Key: vfs.fs.size[/zpool-name,used] # Key: vfs.fs.size[/zpool-name,pfree] # Custom UserParameters for ZFS (add to agent config) UserParameter=zfs.arc.size,sysctl -n kstat.zfs.misc.arcstats.size UserParameter=zfs.arc.hit_ratio,sysctl -n kstat.zfs.misc.arcstats.hits | awk '{h=$1} END {getline t < "/dev/stdin"; print h/(h+t)*100}' <<< $(sysctl -n kstat.zfs.misc.arcstats.misses) UserParameter=zfs.pool.health[*],zpool status $1 | grep state: | awk '{print $2}' UserParameter=zfs.pool.capacity[*],zpool list -Hp -o capacity $1
Add these UserParameters to /usr/local/etc/zabbix7/zabbix_agent2.d/zfs.conf:
shcat > /usr/local/etc/zabbix7/zabbix_agent2.d/zfs.conf << 'EOF' UserParameter=zfs.arc.size,sysctl -n kstat.zfs.misc.arcstats.size UserParameter=zfs.arc.hits,sysctl -n kstat.zfs.misc.arcstats.hits UserParameter=zfs.arc.misses,sysctl -n kstat.zfs.misc.arcstats.misses UserParameter=zfs.pool.health[*],zpool status $1 | grep -c ONLINE UserParameter=zfs.pool.used[*],zpool list -Hp -o allocated $1 UserParameter=zfs.pool.size[*],zpool list -Hp -o size $1 UserParameter=zfs.pool.capacity[*],zpool list -Hp -o capacity $1 EOF service zabbix_agent2 restart
Then create corresponding items and triggers in the Zabbix frontend. Set a trigger on zfs.pool.health to alert when the count of ONLINE entries changes, indicating a degraded or faulted pool.
Jail Monitoring
Monitor FreeBSD jails by running Agent 2 inside each jail, or use UserParameters on the host to report jail status:
shUserParameter=jail.count,jls | tail -n +2 | wc -l | tr -d ' ' UserParameter=jail.running[*],jls -n name | grep -c "^$1$" UserParameter=jail.list,jls -n name | paste -sd,
SNMP Monitoring
Zabbix excels at SNMP monitoring for network devices, printers, UPS units, and any equipment exposing SNMP data.
Configuring SNMP Hosts
Add a network device in the Zabbix frontend:
- Configuration > Hosts > Create host
- Set the host name and IP address
- Under Interfaces, add an SNMP interface with the device's IP and SNMP community string
- Link an appropriate template (Zabbix ships templates for Cisco, Juniper, Linux SNMP, Windows SNMP, and generic network devices)
SNMP v3 Configuration
For secure SNMP v3 with authentication and encryption:
shell# In the host configuration: SNMP version: SNMPv3 Security name: monitoring_user Security level: authPriv Authentication protocol: SHA256 Authentication passphrase: your_auth_passphrase Privacy protocol: AES256 Privacy passphrase: your_priv_passphrase
SNMP Trap Receiver
To receive SNMP traps on the Zabbix server:
shpkg install net-snmp
Configure snmptrapd to forward traps to Zabbix:
sh# /usr/local/etc/snmp/snmptrapd.conf authCommunity log,execute,net public traphandle default /usr/local/bin/zabbix_trap_receiver.pl
Auto-Discovery
Zabbix's network discovery and low-level discovery (LLD) automate host and metric registration.
Network Discovery
Automatically find and register new hosts on your network:
shell# Configuration > Discovery > Create discovery rule Name: Local Network Scan IP Range: 10.0.0.1-254 Update interval: 1h Checks: Zabbix agent "system.hostname", SNMP v2 "sysName.0"
Set up discovery actions to automatically add discovered hosts, link templates, and assign to host groups based on the services they offer.
Low-Level Discovery (LLD)
LLD automatically discovers filesystem mount points, network interfaces, ZFS pools, SNMP OIDs, and other variable-count resources. The FreeBSD agent template includes LLD rules for:
- Filesystem discovery (creates items and triggers for each mount point)
- Network interface discovery (creates items for each interface)
- Block device discovery
Custom LLD for ZFS pools:
shUserParameter=zfs.pool.discovery,zpool list -Hp -o name | awk 'BEGIN{printf "{\"data\":[";sep=""} {printf "%s{\"{#POOLNAME}\":\"%s\"}", sep, $1; sep=","} END{printf "]}"}'
This returns a JSON discovery document that Zabbix uses to automatically create items and triggers for each ZFS pool.
Alerting and Escalation
Zabbix's alerting is one of its strongest enterprise features.
Trigger Expressions
Triggers define conditions that fire alerts:
shell# CPU usage above 85% for 5 minutes avg(/webserver01/system.cpu.util,5m)>85 # Free disk space below 10% last(/webserver01/vfs.fs.size[/,pfree])<10 # ZFS pool capacity above 80% last(/webserver01/zfs.pool.capacity[zroot])>80 # Host unreachable for 3 minutes nodata(/webserver01/agent.ping,3m)=1
Escalation Policies
Zabbix supports multi-step escalation:
- Immediate: send email to on-call engineer
- After 15 minutes: send SMS if not acknowledged
- After 30 minutes: page team lead
- After 1 hour: notify management
Configure escalations under Configuration > Actions. Each step can use different media types (email, SMS, Slack webhook, PagerDuty, custom script).
Slack Integration
sh# Create a media type for Slack webhook # Administration > Media types > Create Name: Slack Type: Webhook Parameters: hook_url: https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK channel: #alerts message: {ALERT.MESSAGE}
Performance at Scale
Zabbix's resource consumption depends on the number of monitored hosts, items per host, and data retention.
Benchmarks on FreeBSD
On a dedicated FreeBSD 14.x server (8 cores, 32 GB RAM, ZFS on NVMe):
- 500 hosts, 200 items each: 100,000 metrics total. Server uses 2-4 GB RAM, 5-10% CPU. PostgreSQL database grows approximately 1 GB/day with 90-day history retention.
- 2,000 hosts, 300 items each: 600,000 metrics total. Server uses 8-12 GB RAM, 20-30% CPU. Requires tuned PostgreSQL with connection pooling (
pgbouncer). Database grows approximately 5 GB/day. - 5,000+ hosts: requires a dedicated database server, possibly Zabbix proxies for distributed collection, and TimescaleDB extension for PostgreSQL to manage history partitioning.
PostgreSQL Tuning for Zabbix
sh# /usr/local/etc/postgresql/postgresql.conf (key settings) shared_buffers = 4GB effective_cache_size = 12GB work_mem = 64MB maintenance_work_mem = 1GB wal_buffers = 64MB checkpoint_completion_target = 0.9 max_connections = 200
Housekeeping
Zabbix's housekeeper process deletes old data. For large installations, this can cause performance issues. Use TimescaleDB partitioning or manual partition management instead:
sh# In zabbix_server.conf HousekeepingFrequency=1 MaxHousekeeperDelete=10000
For installations with more than 1,000 hosts, switch to TimescaleDB:
shpkg install timescaledb # Then run the TimescaleDB migration script provided by Zabbix
Zabbix vs Prometheus
Data model. Zabbix uses a traditional relational model: hosts have items, items have history. Prometheus uses a dimensional time-series model with labels. Prometheus's model is more flexible for dynamic, label-heavy environments (containers, microservices). Zabbix's model maps better to traditional infrastructure with fixed hosts and services.
Data collection. Zabbix primarily pushes (agents send data to server) or polls (server queries targets). Prometheus pulls (scrapes HTTP endpoints). Pull-based monitoring is more natural for ephemeral workloads; push-based is simpler for firewalled environments where monitored hosts cannot accept incoming connections.
Configuration. Zabbix is configured through a web interface with templates, host groups, and actions. Prometheus is configured with YAML files and relabeling rules. Zabbix is more approachable for operators who prefer a GUI. Prometheus fits better in infrastructure-as-code workflows where configuration lives in version control.
Built-in features. Zabbix includes visualization, alerting, escalation, reporting, auto-discovery, and network maps in a single product. Prometheus requires Grafana for visualization and Alertmanager for alerting. Zabbix is more turnkey; the Prometheus ecosystem is more modular.
Scalability. Prometheus scales horizontally with federation and Thanos/Cortex for long-term storage. Zabbix scales vertically (bigger server) and horizontally with proxies. Both handle thousands of hosts, but the operational patterns differ.
Recommendation. Choose Zabbix for traditional infrastructure monitoring with SNMP devices, enterprise escalation policies, and teams that want a unified GUI. Choose Prometheus for cloud-native workloads, container orchestration, and teams comfortable with PromQL and YAML configuration.
Zabbix vs Nagios
Nagios is Zabbix's closest architectural ancestor, and the comparison is straightforward: Zabbix does everything Nagios does, plus more, with a better interface, and without Nagios's configuration file complexity. Nagios's plugin ecosystem is its remaining advantage -- decades of community plugins for obscure checks. Most of those plugins can be executed from Zabbix via the system.run item type or UserParameters, so even that advantage is not exclusive.
If you are running Nagios today, migrating to Zabbix is worth the effort. If you are starting fresh, there is no reason to choose Nagios over Zabbix unless your team has deep Nagios expertise and the environment is already fully configured.
See the Nagios review for a detailed assessment of Nagios on FreeBSD.
FAQ
Q: Can I run the Zabbix server inside a FreeBSD jail?
A: Yes. Run the server, database, and web frontend in a jail with network access. Agent 2 should run on the host or in each jail you want to monitor. Shared memory settings (kern.ipc.shmmax) may need tuning in the jail.
Q: Does Zabbix Agent 2 support FreeBSD?
A: Yes. The Go-based Agent 2 is available as zabbix7-agent2 in the FreeBSD package repository. It supports all standard FreeBSD metrics plus plugins for PostgreSQL, MySQL, Redis, and Docker.
Q: How do I monitor ZFS with Zabbix?
A: Use UserParameters in the agent configuration to expose ZFS metrics via sysctl and zpool commands. Create corresponding items and triggers in the Zabbix frontend. See the ZFS monitoring section above for examples.
Q: What database should I use with Zabbix on FreeBSD?
A: PostgreSQL. It handles Zabbix's write-heavy workload well, has excellent FreeBSD support, and supports TimescaleDB for large-scale history partitioning. MySQL/MariaDB also works but PostgreSQL is the better choice for new deployments.
Q: How much disk space does Zabbix need?
A: Depends on metrics count and retention. A rough estimate: 500 hosts with 200 items each, 90-day history, and 365-day trends uses approximately 30-50 GB of database storage per year. Use PostgreSQL partitioning or TimescaleDB to manage this.
Q: Can Zabbix monitor hosts behind a NAT or firewall?
A: Yes. Use active agent mode (agent initiates connection to server) or deploy a Zabbix Proxy in the remote network. Both methods work with hosts that cannot accept incoming connections.
Q: Is Zabbix free?
A: Yes. Zabbix is fully open-source under the GPL. There is no "community" vs "enterprise" split in functionality. Zabbix LLC offers commercial support contracts but the software itself is identical.
For more monitoring approaches on FreeBSD, see the server monitoring guide.