Feature Request: Allow for all permutations of configurations per each dataset

[helamonster]

Love this project, very useful. However, the control for features (collectors and properties) are enabled/collected per dataset is very limited (coarse). I have the need for finer-grained control over what features are enabled per dataset.

It should be possible to allow for all permutations of all configuration options per each dataset. I propose the following:

• Add flag:
  --include=INCLUDE
  That acts similarly (opposite) to --exclude

• Add finer-grained control over what types of datasets for which snapshots shall be collected
  Instead of (or in addition to) the flag:
  --collector.dataset-snapshot
  Use these:
  --collector.dataset-volume-snapshot
--collector.dataset-filesystem-snapshot

• Add ability to enable bookmark data collection:
  Add argument:
  --collector.dataset-bookmark
--collector.dataset-volume-bookmark
--collector.dataset-filesystem-bookmark

• Add ability to enable snapshot holds data collection:
  Add argument:
  --collector.dataset-snapshot-holds
--collector.dataset-volume-snapshot-holds
--collector.dataset-filesystem-snapshot-holds

• Add ability to selectively enable properties or collectors per zpool/dataset by:
  Most importantly for the --collector.dataset-snapshot (and other snapshot/bookmark) options since snapshot/bookmark data collection is VERY expensive, you may want to limit it down to a specific set of datasets.
  Add argument:
  --dataset XYZ
  That can be specified multiple times. any following --collector* or --properties* arguments will then only be applied to the specified dataset(s)
  Also:
  --include and --exclude should be able to be specified multiple times and behave in the same manner.
  --pool should behave in the same manner (but for pools)
  or add:
  --pools should allow comma-delimited list of pool names
  e.g.
  ./zfs_exporter --pools bpool,rpool \
--collector.dataset-volume-snapshot --properties.dataset-snapshot="logicalused,referenced,used,written" \
--pools data --datasets "^data/my/important/dataset" \
--collector.dataset-snapshot \
--properties.datasetsnapshot="creation,logicalused,referenced,used,written,compressratio,refcompressratio"

• Also, one more thing... add the ability to query all zfs module parameters (e.g. /sys/module/zfs/parameters/*)

This will allow for total zfs information awareness :-)

[pdf]

• Add flag: --include=INCLUDE

This is doable, I suppose they would be applied in sequence if both declared, include followed by exclude probably.

• Add finer-grained control over what types of datasets for which snapshots shall be collected

This is possible, but would likely be done via a separate flag, since --collector.* is a specific structure that maps to a collector/processor for a particular data type.

EDIT: Actually, I'm not sure that this is possible without multiple round-trips, since the ZFS cli only provides list filters for primary types (fs/vol/snap/bookmark), so you probably just need to rely on filtering (e.g. --exclude).

• Add ability to enable bookmark data collection

Doable.

• Add ability to enable snapshot holds data collection

What data would be represented for holds? Wouldn't it just be the destroy_defer and userrefs properties on the snapshot?

Add argument:
--dataset XYZ

How is this different from include/exclude (which are more flexible, as regexps)?

That can be specified multiple times. any following --collector* or --properties* arguments will then only be applied to the specified dataset(s)

This positional concept for flags sounds rather confusing, and is not possible with our current flag parsing. The utility of per-pool/per-dataset property selection seems rather low for the added complexity, and would mean you can't run homogeneous queries across metrics of the same type, since they won't all have the same data available).

--include and --exclude should be able to be specified multiple times and behave in the same manner.

--exclude and --pool may already be specified multiple times, --include (if implemented) would be have the same way.

• Also, one more thing... add the ability to query all zfs module parameters (e.g. /sys/module/zfs/parameters/*)

This project is platform-agnostic, and we build for many operating systems, I might consider this, but it's not likely to be high on my priority list.