prometheus / prometheus/node_exporter
zfs collector - could not parse expected integer value
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 13.8k
- Forks
- 2.7k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 8
Description
Description
It's very similar to https://github.com/prometheus/node_exporter/issues/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,
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the zfs collector and the parsing path that reports “could not parse expected integer value” for memory_available_bytes. Reproduce the negative values shown in /proc/spl/kstat/zfs/arcstats, then determine how invalid metric values should be handled without stopping the remaining collectors. Done means the zfs failure no longer halts all metric processing and the behavior is covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, prometheus
- Domain
- observability-sre
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100