Monitoring pool space utilization via SNMP

I’m attempting to monitor disk usage of my pools using SNMP, but the ZPOOL OID ( does not seem to report anything about pool size or utilization.

Instead I found, that the ZVOL OID ( that does contain UsedBytes and AvailableBytes, will actually enumerate pools and not ZVOLs as long as there are no actual ZVOLs created on the server and this is exactly what I need!
But as soon as I create a ZVOL somewhere, this changes, and the ZVOL OID now only contains that ZVOL (which actually makes more sense, but is not what I need :frowning:).

Does anyone have any experience monitoring pool-space via SNMP, while also having ZVOLs on the server?

I use the HOST-RESOURCES-MIB and the storage table with Observium. Gives you all datasets - and the top level dataset is of course your entire pool.

At first glance this looked very promising, but there are some issues - not all of which have a workaround :frowning::

  • Both ::hrStorageSize and ::hrStorageUsed are reported in the units from ::hrStorageAllocationUnits (which looks like it corresponds to the recordsize of the dataset). This shouldn’t be a problem, as it’s just a matter of multiplying them, but for some reason ::hrStorageAllocationUnits is reported as 0 for some of my datasets even though those datasets are children of, and inheriting their recordsize from, others that report the correct ::hrStorageAllocationUnits value…
  • ::hrStorageUsed corresponds to “Data Written” in the TrueNAS UI, which does not seem to include data used by snapshots or child-datasets. I want the “Total Allocated” value, but I don’t see any way of constructing that based on the values available…
  • ::hrStorageSize seems to correspond to “Space Available to Dataset” + “Data Written”… So in order to get the total size of a pool, you’d have to take ::hrStorageSize from one dataset in the pool and add the ::hrStorageUsed value of all other datasets in the pool.
  • ZVOLs are not included here, so getting the total size of a pool that includes ZVOLs becomes even more messy, but it is probably possible by combining it with data from the ZVOL OID mentioned in the OP.

Even though it will be somewhat messy, it looks like it should be possible to cobble together something usable from this, and it is probably the best option for now until this is hopefully implemented at some point