Buyer’s Guide - August 2026

The best ZFS monitoring tools, ranked by people who run pools

Q: Does TrueNAS have built-in ZFS monitoring?

Yes. The TrueNAS Reporting screen graphs ZFS metrics including ARC size, hit ratio, demand data, and prefetch data, and dashboard widgets show pool usage, disks with ZFS errors, and last scan errors. The limitation is scope: monitoring covers the TrueNAS host itself, and fleet-wide views require TrueCommand or the paid TrueNAS Connect subscription.

Q: What is the difference between ARC and L2ARC, and why monitor both?

ARC is the in-RAM adaptive replacement cache; L2ARC is the SSD-backed secondary cache that extends it. Monitor ARC hit ratio, size, and memory pressure to tune how much RAM the cache gets. Monitor L2ARC hits, misses, and read and write bytes, because a low L2ARC hit ratio means reads are falling through to disk and adding latency. Both Telegraf and Netdata expose ARC and L2ARC statistics.

Q: How often should ZFS monitoring collect metrics?

Per-second collection helps troubleshoot latency, IOPS, and bandwidth spikes that coarser sampling averages away. Intervals of 10 to 60 seconds are enough for capacity and health trending, and health checks every few minutes still catch pool degradation promptly. Faster collection costs more CPU and storage, so tune the interval to your fleet size rather than defaulting to the maximum everywhere.

ZFS has its own health states, its own cache hierarchy, and its own maintenance cycle, and most generic monitoring stacks see none of it by default. We ranked seven tools on ZFS metric depth, alerting, time to first useful chart, and how honestly the cost scales, so you can pick the one that fits a TrueNAS box, a Proxmox host, or a fleet of OpenZFS storage servers.

Start with Netdata (free) Jump to rankings

The best ZFS monitoring tools, ranked by people who run pools product interface

Why this list exists

ZFS monitoring is not server monitoring with extra disks. A pool has health states (online, degraded, faulted, unavail) that generic disk dashboards never check, a two-tier cache (ARC and L2ARC) whose hit ratio decides whether your latency is fine or terrible, and a scrub and resilver cycle that generic tools ignore entirely. The mistake buyers make is assuming any monitoring agent can see all of this. Most cannot. They need a dedicated collector, a community template, or a plugin, and many cover pool health while missing ARC performance, or the reverse.

Three dimensions decide whether a tool actually works for a ZFS operator:

Metric depth. Does it expose pool health state, per-vdev state, space utilization, fragmentation, ARC and L2ARC statistics, and scrub status? Generic disk I/O does not count.
Alerting without assembly. Can it tell you a pool went degraded or a vdev faulted without you hand-writing alert rules and standing up a separate alertmanager?
Time to first useful chart. Auto-detection and prebuilt checks beat an afternoon of wiring exporters, templates, and dashboards together.

One note on pricing: we do not quote competitor list prices, because they change, vary by region and contract, and are easy to game in a listicle. Instead we describe the shape of each bill and what makes it grow, and we link every vendor’s official pricing page so you can check the current numbers yourself. For Netdata’s own plans, see our pricing page. For operator-level background on what to track and why, see the ZFS guides section.

We assembled the shortlist from the tools ZFS operators actually discuss and deploy: purpose-built collectors, the dominant open-source metrics stacks, enterprise platforms with ZFS templates, and the built-in reporting in TrueNAS. We verified each tool’s ZFS coverage against its own documentation and integration catalogs, not against marketing pages.

ZFS metric depth and alerting carry the most weight, because those are the two things that fail silently in generic stacks. A tool can have beautiful dashboards and still never tell you a pool went degraded at 3 a.m. Deployment effort and data granularity matter next, since most ZFS operators run small teams and cannot spend a week assembling a stack per storage host.

Tester credit

Compiled by the Netdata team - Updated August 12, 2026

Sources verified

Scoring criteria

ZFS metric depth 25%
Pool state, vdev state, space, fragmentation, ARC/L2ARC, scrub status
Alerting and anomaly detection 20%
Proactive degraded-pool and capacity alerts without hand-built rules
Deployment and time-to-value 15%
Auto-detection and prebuilt checks over DIY assembly
Data granularity and retention 15%
Collection interval and historical depth for capacity planning
Ecosystem and extensibility 10%
Community dashboards, plugins, and integrations
Cost model transparency 10%
How predictably the bill grows with the fleet
Platform coverage 5%
Linux, FreeBSD, Solaris/illumos, TrueNAS

Vendor 01 / 07 · #netdata

Netdata

Real-time infrastructure monitoring with a dedicated ZFS pool collector, built-in pool health alerts, and per-second granularity.

Best for

Operators who want ZFS pool health, vdev state, and space utilization visible within minutes of install
Fleets where per-second metric granularity and built-in anomaly detection matter
Teams that want alerting without assembling a separate Prometheus and Grafana stack

Pricing

Agents are open source (AGPL) and free to run on every node
Netdata Cloud Business is per-node, from $4.50/node/month on annual plans, with the per-node price decreasing as node count grows
A free Cloud tier exists for small fleets
The bill grows predictably with node count, not with metric volume

Pros

Dedicated go.d/zfspool collector monitors pool space utilization, fragmentation, pool health state, and per-vdev health state via the zpool CLI
Separate ZFS ARC collector tracks cache hit and miss behavior, supported across platforms per Netdata’s integration catalog
Built-in alerts for pool space utilization, degraded pools, and faulted vdevs, with no separate alertmanager to configure
Per-second collection platform-wide; the zfspool collector defaults to 10 seconds and is tunable via update_every
Runs on Linux and FreeBSD; ML-based anomaly detection surfaces unusual pool behavior without hand-tuned thresholds

Where teams pair it

Scrub progress and snapshot age are not in the zfspool collector’s metric set; pair it with a small script or a Checkmk community plugin if you need scrub tracking
The zfspool collector does not run on macOS (Linux and BSD only)

Verdict

Netdata is the only tool in this list that ships a purpose-built ZFS pool collector with health-state, vdev-state, fragmentation, and space-utilization metrics plus matching alerts out of the box, at per-second granularity, with zero stack assembly. For a Proxmox host, a FreeBSD storage server, or a fleet of OpenZFS machines, that is the shortest path from install to knowing a pool went degraded. The honest caveat: scrub progress and snapshot age need a script alongside it, and the collector is Linux and BSD only. If your ZFS lives entirely inside TrueNAS, the built-in reporting below may be enough on its own.

Start free -> See ZFS pool monitoring ->

Vendor 02 / 07 · #prometheus-grafana

Prometheus + Grafana

Open-source metrics stack pairing Prometheus scraping with Grafana dashboards, widely used for ZFS pool and ARC visualization.

Best for

Teams already running Prometheus who want ZFS metrics in the same scrape pool
Operators who want community-built ZFS dashboards and full control over retention and alert rules
Homelab and production users comfortable assembling and maintaining a multi-component stack

Pricing

Prometheus and Grafana OSS are open source and self-hosted; you operate them yourself
Grafana Cloud has a free tier limited by active users; paid tiers are priced per active user plus a platform fee
Enterprise Grafana is a custom annual contract
The real cost is operational: exporters, Grafana, Alertmanager, and long-term storage all need upkeep

Pros

node_exporter ships a built-in ZFS collector exposing ARC, vdev, and pool performance stats on Linux, FreeBSD, and Solaris
Dedicated exporters such as pdf/zfs_exporter add pool health, filesystem, snapshot, and volume metrics with configurable property selection
Mature dashboard ecosystem, including the node-zfs-stats dashboard (7968) and ZFS Pool Metrics (15362)
Alerting via Alertmanager with community rule sets for ZFS

Cons

Requires assembling and operating Prometheus, exporters, Grafana, and Alertmanager as separate components
Default scrape intervals are typically 15 seconds or longer, coarser than per-second collectors
Pool health state is exposed as a metric, but interpreting it requires custom alert rules; there is no out-of-the-box ZFS alert pack
Retention is limited by local disk unless you add long-term storage such as Thanos

Verdict

This is the deepest DIY option for ZFS. Between node_exporter’s built-in collector and pdf/zfs_exporter, you can get pool health, snapshots, ARC, and vdev stats into a mature dashboard ecosystem, and it covers Solaris where most tools do not. The cost is assembly and maintenance: nothing about degraded-pool alerting works until you write the rules yourself. If you already run Prometheus, adding ZFS is nearly free. If you do not, standing up this stack just for storage monitoring is a week of work other tools on this list avoid.

Read full Netdata vs Grafana -> Grafana pricing ->

Vendor 03 / 07 · #zabbix

Zabbix

Enterprise-grade open-source monitoring platform with community-maintained ZFS templates for pool health, capacity, and performance.

Best for

Organizations that want a full enterprise monitoring platform without per-node license costs
Teams already standardized on Zabbix that need ZFS pool health and capacity in the same tool
Large fleets where Zabbix’s proxy-based distributed monitoring is an advantage

Pricing

Open source under AGPLv3; no license fee for the software itself, but you operate it
Paid subscriptions add support SLAs, long-term maintenance, and guaranteed security fixes
Zabbix Cloud is available as a hosted SaaS option

Pros

Mature platform with discovery, triggers, notifications, and distributed proxies
Multiple community ZFS templates cover pool health, dataset usage, and performance, such as zabbix_zfs-on-linux
Fully open source with no feature-gated commercial edition
ZFS monitoring works on Linux and FreeBSD agents via zpool and zfs command parsing

Cons

ZFS support relies on community templates and user parameters, not a first-party maintained integration
Community templates have known breakage across distros, including Ubuntu 22.04 zfs binary path issues
Template setup requires manual import, user-parameter configuration, and trigger tuning
Default polling intervals are typically 30 seconds to minutes, coarser than per-second collectors

Verdict

Zabbix gives you enterprise-grade alerting, escalations, and distributed proxies with no license fee, and the community ZFS templates cover pool health and capacity reasonably well. The catch is that ZFS is community territory: templates break across distro releases, and maintaining them is your job. If Zabbix is already your standard, adding ZFS monitoring is a template import away. If it is not, adopting an enterprise monitoring platform just to watch pools is heavier than the problem requires.

Read full Netdata vs Zabbix -> Zabbix subscriptions ->

Vendor 04 / 07 · #checkmk

Checkmk

Open-core monitoring platform with native ZFS pool checks for size, status, and filesystem usage.

Best for

Teams that want agent-based monitoring with built-in ZFS checks and a polished UI
Organizations that prefer service-based pricing over per-host or per-node models
Mixed estates where ZFS storage servers sit alongside network and application monitoring

Pricing

Raw edition is open source and self-hosted; you operate it yourself
Paid editions (Enterprise, Cloud) are priced per monitored service, with roughly 30 services per host as a sizing reference
A ZFS pool with many datasets can consume many billable services, so dense storage hosts grow the bill faster than plain servers

Pros

Native checks for ZFS pool size (zpool), pool status (zpool_status), and filesystem usage (zfsget)
Pool status check reads zpool status -x and raises CRITICAL on degraded pools, WARNING on CRC or other errors
Community plugins add pool I/O performance plus snapshot-age and scrub-status checks
Agent-based discovery creates one service per pool automatically

Cons

Native zpool and zpool_status checks target Solaris agents; Linux ZFS monitoring relies on community plugins
No ARC or L2ARC cache statistics out of the box
Service-based pricing penalizes dataset-dense storage servers

Verdict

Checkmk’s native pool status check is genuinely good: zpool status -x parsed into CRITICAL and WARNING states with automatic per-pool service discovery is exactly what a ZFS operator wants. The problem is where it runs. The native checks target Solaris agents, so the OpenZFS-on-Linux majority leans on community plugins, and ARC analytics are absent either way. For illumos and Solaris shops, or mixed estates already on Checkmk, it earns its place. For Linux-first ZFS fleets, expect plugin work.

Read full Netdata vs Checkmk -> Checkmk pricing ->

Vendor 05 / 07 · #telegraf-influxdb

Telegraf + InfluxDB

Open-source metrics pipeline pairing the Telegraf ZFS input plugin with InfluxDB time-series storage and analysis.

Best for

Teams that want ZFS ARC and cache statistics in a purpose-built time-series database
Users already on InfluxDB who want ZFS metrics alongside other Telegraf-collected data
Analytics-focused operators who want to query ZFS metrics with Flux or InfluxQL

Pricing

Telegraf and InfluxDB OSS are open source and self-hosted; you operate them yourself
InfluxDB Cloud is usage-based, billed on data ingested, query count, storage, and data transferred out
The bill grows with write volume and query activity, not host count, so busy dashboards cost more than idle ones

Pros

Telegraf ZFS input plugin collects ARC stats (hits, misses, size, L2ARC), zfetchstats, and vdev cache stats on Linux and FreeBSD
Optional pool metrics (I/O counts, latency, capacity) and dataset metrics via configuration flags
Open source pipeline with no per-host licensing
Strong fit for cache-tuning analysis over long retention windows

Cons

Pool and dataset statistics are disabled by default and must be explicitly enabled
Dataset metrics are only available on FreeBSD; Linux users get ARC and pool stats only
No built-in alerting for ZFS pool health; you must pair with Grafana, Kapacitor, or another alerting layer
Requires assembling Telegraf, InfluxDB, and a visualization and alerting tool yourself

Verdict

Telegraf’s ZFS plugin is the best pure ARC and L2ARC analytics collector on this list, and InfluxDB is a comfortable home for long-term cache-tuning analysis. But this is a metrics pipeline, not a health monitor: there is no native pool health state metric on Linux and no alerting until you bolt one on. Use it when cache performance analysis is the goal and you already run InfluxDB. Do not rely on it as the thing that pages you when a pool degrades.

Telegraf ZFS plugin docs -> InfluxDB pricing ->

Vendor 06 / 07 · #nagios

Nagios

Long-standing open-source monitoring platform with a mature ecosystem of ZFS pool health check plugins.

Best for

Organizations with existing Nagios expertise and infrastructure
Teams that want simple plugin-based ZFS health checks without a metrics platform
Environments where check_zfs-style plugins are already part of the monitoring standard

Pricing

Nagios Core is open source and self-hosted; you operate it yourself
Nagios XI is commercial, licensed per monitored node (unique IP or URL), with annual maintenance on top
The bill grows with node count, which stings on large storage fleets

Pros

Mature plugin ecosystem with multiple ZFS checks on Nagios Exchange (check_zfs, check_zpools.sh, check_zpool_zfsonlinux)
Plugins parse zpool status and alert on DEGRADED or worse pool states, including resilver progress
check_zpools supports Solaris, FreeBSD, Linux, and smartOS
Nagios Core remains fully open source

Cons

ZFS plugins are community-maintained with varying quality; some are Solaris-specific or unmaintained
check_zpools requires ZFS 2.2.2+ and jq for JSON output parsing
No time-series metrics: plugins are point-in-time health checks, so no capacity trending or ARC analytics
Dated dashboards compared to every other tool on this list

Verdict

Nagios answers the most important ZFS question, is my pool healthy, with plugins that have been parsing zpool status for years, and check_zpools even reports resilver progress across four platforms. What it cannot do is trend anything: no capacity history, no ARC analytics, no graphs worth looking at without heavy add-ons. In a shop that already runs Nagios, the ZFS plugins are an easy win. As a fresh deployment in 2026, it buys you health checks and nothing else.

Read full Netdata vs Nagios -> Nagios pricing ->

Vendor 07 / 07 · #truenas

TrueNAS

Open-source storage operating system with built-in ZFS reporting, dashboard widgets, and pool health visibility.

Best for

TrueNAS users who want ZFS health and performance visibility without installing a separate monitoring tool
Homelab and small-business storage operators running CORE or SCALE
Organizations that want storage-vendor-supported ZFS monitoring

Pricing

TrueNAS CORE and SCALE are open source and self-hosted; you operate them yourself
TrueNAS Enterprise bundles software with certified hardware and support contracts
TrueNAS Connect adds a paid subscription tier for cloud-connected monitoring features

Pros

Built-in Reporting screen graphs ZFS metrics including ARC size, hit ratio, demand data, and prefetch data
Dashboard widgets show pool usage, disks with ZFS errors, and last scan errors at a glance
Zero additional setup for ZFS visibility on TrueNAS systems
CORE and SCALE carry no license fee

Cons

Monitoring is limited to the TrueNAS host itself; no fleet-wide ZFS view without TrueCommand or TrueNAS Connect
No built-in alerting for pool health degradation beyond the UI and email notifications
Cannot monitor non-TrueNAS ZFS servers at all
Historical reporting retention is limited compared to dedicated metrics platforms

Verdict

If all of your ZFS lives on TrueNAS, start here: the Reporting screen already graphs ARC hit ratio and pool usage, and the dashboard surfaces disks with ZFS errors and last scan results with zero setup. It is the easiest entry on this list precisely because it is not really a monitoring tool. The moment you have a second storage host, a Proxmox box, or any ZFS outside TrueNAS, you need one of the other six tools alongside it. Think of it as the baseline, not the answer.

TrueNAS reporting docs -> TrueNAS Enterprise ->

Frequently asked questions

What ZFS metrics should I monitor on a daily basis?

Start with pool health state (online, degraded, faulted, unavail) via zpool status, plus per-vdev error counts and resilver progress. Track space utilization and fragmentation per pool so capacity breaches never surprise you. On the performance side, watch ARC hit ratio, size, and evictions. Finally, check scrub status and last scrub results, since a scrub that has not run in months is a risk hiding in plain sight.

How do I get alerted when a ZFS pool fails or degrades?

The fastest path is a monitoring tool with built-in ZFS pool health alerts. Netdata ships built-in alerts for degraded pools, faulted vdevs, and capacity breaches with zero configuration. On Linux, ZED (the ZFS Event Daemon) can also send email notifications for pool events with no extra tooling. Zabbix community templates provide triggers on pool health state, and Nagios check_zfs plugins parse zpool status and raise CRITICAL on DEGRADED. ZED plus one metrics platform covers both instant events and slow trends.

Can I monitor ZFS with Prometheus and Grafana?

Yes, and it is the most common DIY route. node_exporter includes a ZFS collector exposing ARC, vdev, and pool stats on Linux, FreeBSD, and Solaris, and pdf/zfs_exporter adds pool health, filesystem, snapshot, and volume metrics. Community Grafana dashboards such as node-zfs-stats (7968) and ZFS Pool Metrics (15362) give you visualization quickly. The gap is alerting: you configure Alertmanager rules yourself, and there is no maintained out-of-the-box ZFS alert pack.

Does TrueNAS have built-in ZFS monitoring?

What is the difference between ARC and L2ARC, and why monitor both?

How often should ZFS monitoring collect metrics?

What is ZED and do I still need a separate monitoring tool?

ZED is the ZFS Event Daemon on Linux. It reacts to pool events in real time and can send email notifications when something goes wrong. What it does not do is store anything: there is no history, no trends, no dashboards. A monitoring tool adds time-series history, fleet-wide visibility, and integration with your existing alerting pipelines. Netdata, Zabbix, and Prometheus all complement ZED rather than replace it.

How do I monitor ZFS scrub progress and results?

zpool status shows scrub progress, the last scrub date, and error counts, and simple scripts can parse that output and alert on non-zero error counts. Checkmk has a community plugin covering snapshot age and scrub status. Be aware that Netdata’s zfspool collector does not expose scrub progress, so if scrub tracking matters to you, pair it with a script or one of those plugins rather than assuming any single tool covers it.

The best ZFS monitoring tools, ranked by people who run pools

How we evaluated ZFS monitoring tools

Netdata

Prometheus + Grafana

Zabbix

Checkmk

Telegraf + InfluxDB

Nagios

TrueNAS

Frequently asked questions

Book Your Free Demo