Prometheus sink handling of metric help is incorrect

[maxb]

I came here via investigating why a dependent project (HashiCorp Consul) was emitting extra spurious metrics with differing label sets. I discovered it's actually a suboptimal work-around for go-metrics' API for specifying metrics help.

Prometheus very strongly recommends that every metric name should be associated with only one set of label keys - only the label values should differ.

Consequentially, Prometheus' metric representation format, only associates metric help strings with the metric name - labels are ignored.

go-metrics makes a conflicting decision to associate metric help with metric type, name, label keys and values.

The overall consequence for users, is that it becomes impossible, using go-metrics, to specify metric help, for a metric which requires label values, which are only known at runtime - which is quite a common pattern.

Unless, that is, they break with the Prometheus recommendation that every metric name should be associated with only one set of label keys, and configure go-metrics with a dummy metric with an empty label set, to carry the help message, and write all their actual metrics using the same metric name, but a populated label set. This is the suboptimal workaround I spoke of at the start.

To fix this:

• The help map within a PrometheusSink should change from being keyed on type.name;labelkey=labelvalue to just name
• There should be a new Definition object similar to Gauge/Counter/SummaryDefinition, which only populates a name => help mapping for future use with ephemeral metrics, but does not create any metric.