Same metric name, different set of label names

We have a lot of Micrometer users requesting that we support registering metrics with the same name but a different set of labels (https://github.com/micrometer-metrics/micrometer/issues/877) for Prometheus. This repo, the official prometheus java client, does not allow this using the built-in types, as can be demonstrated by the following unit test:

@Test
void promClientSameMetricNameDifferentLabels() {
    CollectorRegistry registry = new CollectorRegistry();
    Counter counter = Counter.build().name("api_response").labelNames("outcome").help(" ")
            .register(registry);
    Counter counter2 = Counter.build().name("api_response").labelNames("outcome", "error").help(" ")
            .register(registry); // fails with "Collector already registered that provides name: api_response_total"
}

It is interesting to note, however, that the Prometheus server will scrape the following without any seeming issue.

# HELP responses
# TYPE app_responses_total counter
app_responses_total{uri="/", outcome="SUCCESS"} 10
app_responses_total{uri="/", outcome="FAILURE", error="INVALID_REQUEST"} 2
app_responses_total{uri="/", outcome="FAILURE", error="DATA_NOT_FOUND"} 3

We have a custom Collector implementation for converting from Micrometer metrics to Prometheus metrics. We have received a pull request in Micrometer with changes that would allow Micrometer to produce a scape endpoint like above, circumventing the exception the Prometheus java client would otherwise throw when registering a metric with a different set of labels. See https://github.com/micrometer-metrics/micrometer/pull/2653.

I am opening an issue here because I would rather we did not do something in Micrometer that is intentionally guarded against in the official java client for Prometheus. I am not sure of all the implications supporting something like this might have on consumers. Is preventing different labels still an intentional choice here and are there plans for this library to support that? Would you recommend we avoid allowing it as well in Micrometer? Why does the Prometheus server scrape such output without error if it is considered an error in the client? I appreciate any advice we can get on this from the Prometheus maintainers.

[nhartner]

This label restriction is some Prometheus dogma that needs to be reevaluated. Consider how many people are asking for a feature that they would find valuable and which technically is already possible. The main reason clients like the Java client don’t support it appears to be documentation dogma.

[stolsvik]

@brian-brazil Think of it this way, if you suddenly pull in a library that has a clashing metric name rather than having an obvious failure at startup indicating that the name clash needs fixing instead your graphs/alerts will silently break.

Well, the current alternative then is to not use the other library, isn’t it?

Currently, the “solution” for this problem in micrometer is to just ignore the second registration, which is unfortunate along multiple axes - but it is pretty much forced to do that to not break exactly that usage scenario.

In addition, if those two libraries do use the same name (which I actually would find strange, I myself always add some kind of “library-identifier” element to such metrics), it should still be possible to distinguish them by their differing use of labels. This must be a fact, as otherwise - if they used the same labels too - the java client would actually allow the registration.