The original case for this was the ability to filter the disk usage stats by filesystem type, so that duplicate entries for nfs partitions, and meaningless entries like the capacity of /proc weren't submitted.

In order to do this in a way that works for any plugin, a plugin's configuration can now have two subsections: tagpass and tagdrop.

An example configuration section would look like this:

# Read metrics about disk usage by mount point
[disk]
interval = "1m" # Run at a 1 minute interval instead of the default

[disk.tagpass]
fstype = [ "ext4", "xfs" ]
path = [ "/", /opt", "/home" ]

[disk.tagdrop]
path = [ "/" ]

It's important to note that at the moment, the multiple tag filters are OR'd together, so in the example above the 'tag pass' test will succeed if the (filesystem is ext4 or xfs) or (the path is /opt or /home). The tag contents are checked as an exact match. The measurement names are tested as a prefix so that a filter of 'foo' will catch 'foobar', 'foobaz', and so on. This didn't make as much sense with the tags, as you would encounter situations like filtering the root filesystem '/' and accidentally matching all others.

All the measurement pass and drop filters are run first, and so overrule the tag pass and drop filters. All the tag pass filters are checked, then all the tag drop filters are checked. This continues the way that the measurement name pass and drop are working.

Potential points for discussion:

1. I looked at a few ways of encoding this configuration in toml and thought this was the clearest, but I'm open to suggestions for improvements.
2. You could make a case that with multiple tag filters, they should be 'AND' rather than 'OR'. For example, 'if the filesystem type is (ext4 or xfs) AND the path is ( / or /opt or /home )' ...