Description
It's very similar to #1158
kstat.zfs.misc.arcstats.memory_available_bytes can have negative values.
Alloy prometheus.exporter.unix is the bundled node_exporter.
I realize that this is also a bug in ZFS. However, this bug brings the entire Alloy node_exporter to a halt. When this happens, no metrics are processed at all.
Logs
alloy[350168]: ts=2026-08-21T08:35:06.952246333Z level=error msg="collector failed" component_path=/ component_id=prometheus.exporter.unix.exporter_unix name=zfs duration_seconds=0.001078926 err="could not parse expected integer value for \"kstat.zfs.misc.arcstats.memory_available_bytes\""
Values
# while true; do grep memory_available_bytes /proc/spl/kstat/zfs/arcstats; sleep 1; done
memory_available_bytes 3 -5664982784
memory_available_bytes 3 -5303375616
memory_available_bytes 3 -4338423552
memory_available_bytes 3 -4106675968
memory_available_bytes 3 -3731105536
memory_available_bytes 3 -3580057344
Expected behavior
If the measured values for the metrics fall outside the specification, perhaps you should simply ignore that metric and continue processing the rest.
For some metrics, it would certainly be possible to debate whether to return 0 instead.
But I realize that whether this would even make sense would depend heavily on the specific metric, and it would also be difficult to determine when a particular metric actually means what it’s supposed to.
Simply not reporting them at all would be the much simpler and more consistent approach.
Workaround
Duplicate scrape & prometheus.exporter.unix for zfs and disable the zfs collector in the first exporter. So only zfs metrics are sometimes missing,
Description
It's very similar to #1158
kstat.zfs.misc.arcstats.memory_available_bytes can have negative values.
Alloy prometheus.exporter.unix is the bundled node_exporter.
I realize that this is also a bug in ZFS. However, this bug brings the entire Alloy node_exporter to a halt. When this happens, no metrics are processed at all.
Logs
Values
# while true; do grep memory_available_bytes /proc/spl/kstat/zfs/arcstats; sleep 1; done memory_available_bytes 3 -5664982784 memory_available_bytes 3 -5303375616 memory_available_bytes 3 -4338423552 memory_available_bytes 3 -4106675968 memory_available_bytes 3 -3731105536 memory_available_bytes 3 -3580057344Expected behavior
If the measured values for the metrics fall outside the specification, perhaps you should simply ignore that metric and continue processing the rest.
For some metrics, it would certainly be possible to debate whether to return 0 instead.
But I realize that whether this would even make sense would depend heavily on the specific metric, and it would also be difficult to determine when a particular metric actually means what it’s supposed to.
Simply not reporting them at all would be the much simpler and more consistent approach.
Workaround
Duplicate scrape & prometheus.exporter.unix for zfs and disable the zfs collector in the first exporter. So only zfs metrics are sometimes missing,