Add direct support for new OpenMetrics types: GaugeHistogram, StateSet and Info

[JnRouvignac]

OpenMetrics 1.0.0 added the metric types GaugeHistogram, StateSet and Info.

How can I output them with the PrometheusMeterRegistry?

prometheus/client_java added the classes Enumeration and Info in response (https://github.com/prometheus/client_java/pull/615), and these correspond to STATE_SET, INFO. However, I see no new class corresponding to GaugeHistogram, but I think these should be handled as a set of gauges like in this unit test: https://github.com/prometheus/client_java/blob/master/simpleclient_common/src/test/java/io/prometheus/client/exporter/common/TextFormatTest.java#L172-L203 Nevertheless I have asked the question in (https://github.com/prometheus/client_java/issues/807), just in case I am missing something.

I have looked at where micrometer uses the new enum values from prometheus simpleclient, and the answer is nowhere. Here are the enum values that I looked for:

• Collector.Type.STATE_SET
• Collector.Type.INFO
• Collector.Type.GAUGE_HISTOGRAM

To conclude, I could not find how t make use of the new OpenMetrics types with the prometheus registry.

Suggested labels for this issue: enhancement, registry: prometheus

[JnRouvignac]

Here is my attempt at using both prometheus and micrometer APIs to output the GaugeHistogram type: https://github.com/JnRouvignac/test_openmetrics

[shakuzen]

Thanks for opening the issue.

Let's consider what we can do for each type.

Info

I don't know that it makes sense to have a new Micrometer meter type for this unless most metrics backends have a dedicated type for this, which is essentially a gauge with a value that must be 1. It would probably be sufficient to check for gauges with names ending in .info (and with a value of 1?) and treat those as Info type in PrometheusMeterRegistry. We could then document that we do this conversion. Does that sound like a reasonable solution? We already have JvmInfoMetrics which would get converted under the proposal, and had OpenMetrics Info type in mind when made.

StateSet

This seems more tricky to support, and again I'm not sure a new Micrometer meter type for this makes sense, but I'm not sure how we could support this on first thought. Proposals welcome.

GaugeHistogram

I think GaugeHistogram corresponds to our LongTaskTimer type conceptually, at least when used for time distributions. If you want a GaugeHistogram for something not time-based, then we don't have a type to capture that conceptually right now. Another problem is that we and the prometheus client support both the prometheus text format (which doesn't know about GaugeHistograms) and the openmetrics format. We're registering LongTaskTimer as a Prometheus Histogram or Summary type now depending on configuration. This was never technically right, but we didn't have GaugeHistogram before OpenMetrics. From the test you shared, it looks like the Prometheus client falls back to the Histogram type when writing GaugeHistogram types to Prometheus text format, which makes sense except that it's not producing a valid Histogram - Histogram requires _sum and _count, not _gsum and _gcount. It will be a breaking change for users if we switch LongTaskTimer to GaugeHistogram with _gsum and _gcount when they're using Prometheus text format. I'm not sure what we should do on the Micrometer side given this.

[JnRouvignac]

Info

Fine by me. :+1:

StateSet

I don't know for sure. On our side we are using gauges with dimensions to emulate the StateSet.

The StateSet corresponds to the enum values present in an EnumSet. When there is no EnumSet, but just one enum value, it's like if there was an EnumSet with a single value in it.

GaugeHistogram

I think GaugeHistogram corresponds to our LongTaskTimer type conceptually, at least when used for time distributions.

Given the name I was far from thinking they would have been similar conceptually!

If you want a GaugeHistogram for something not time-based, then we don't have a type to capture that conceptually right now.

Blast.

From the test you shared, it looks like the Prometheus client falls back to the Histogram type when writing GaugeHistogram types to Prometheus text format, which makes sense except that it's not producing a valid Histogram - Histogram requires _sum and _count, not _gsum and _gcount. It will be a breaking change for users if we switch LongTaskTimer to GaugeHistogram with _gsum and _gcount when they're using Prometheus text format.

Good spot, I did not realize it. I will ask the question on the prometheus client_java repo about it.