Detect name collisions around _bucket, _count, _sum, and the quantile label during Gathering of metrics

[beorn7]

Summaries and histograms implicitly create time series named xxx_count and xxx_sum. In addition, histograms implicitly create time series named xxx_bucket. While this should not strictly be a concern of the client (in principle, a future version of the Prometheus server could treat summaries and histograms as 1st class types that do not get dissected into a number of series with the names described above), we should nevertheless avoid name collisions. Thus:

Once a summary or histogram named xxx is registered, any metric named xxx_count, xxx_sum, or xxx_bucket (in case of histograms) must be rejected (and vice versa).

[juliusv]

A user on IRC just ran into this (via different sources pushing metrics to the StatsD exporter).

[beorn7]

Currently, the Desc doesn't contain the metric type (for a reason, but that would take too long to explain, and the relevance of that reason has decreased a lot over time). Thus, we cannot detect those collisions during registration time (unless we want to ban all metrics ending on _count, _sum, and _bucket).

With the changes planned for v0.10 (i.e. #222 ), a registration check as described above will be possible.

Thus, my plan for v0.9 is to detect the collisions during scrape time (and therefore not expose something that a current Prometheus server cannot ingest). In v0.10, those collisions will be detected during registration time.

Also, we can right now prevent labels called quantile in summaries with quantiles (simply on instantiation time of a Summary type, I think this is a fair reason to panic).

I will rename this issue accordingly and create a separate one for the v0.10 part.

[beorn7]

While this should not strictly be a concern of the client (in principle, a future version of the Prometheus server could treat summaries and histograms as 1st class types that do not get dissected into a number of series with the names described above), we should nevertheless avoid name collisions.

Ha, here you can see my wishful thinking more than three years ago. Now we have the flattening even in the only exposition format the server understands…