I agree, that's quite unfortunate. Initially we always just dumped pretty much raw names from proc but changed that eventually (#150). The ZFS collector wasn't change. Unfortunately changing it now will be a breaking change. Still, something we should probably do. @SuperQ wdyt?

Yes, I never liked the dumping of random proc contents with no filtering. This leads to random breakage.

To minimise this breaking change, how about cleaning up the references, but also providing a flag to control whether the old names should be published or not?

--publish-lagecy-names can default to true, allowing the cleanup to be a no-op immediately. In a future release, the flag can be disabled and eventually retired.

Yeah I was thinking about some sort of 'translation' layer to support that for all collectors. So if you come up with a clean pattern for doing this, that would make sense. Beside that, we provided recording rules for breaking changes in the past.

How about:

1. Flag guard the logic that enables the new, cleaned up named. Default it to false
2. Provide rewrite recording rules and declare future date, to give users enough notice
3. Once future date arrives, flip the flag to true.
4. Future Date + X months, remove the feature flag and legacy naming

Although it takes a while to complete all the states, I've used this pattern quite a lot professionally.

@conallob I don't like maintaining those recording rules. IMO it's better for handing the changes in PromQL downstream with queries like sum(new_metric_name) or sum(old_metric_name). This way the user doesn't have to store two copies of the data.

Simplified timeline:

1. Flag guard the logic that enables the new, cleaned up named. Default it to false
2. Next major release (currently 2.0.0) we flip the flag to true and drop the old metris.