Promtool should support openmetrics

[roidelapluie]

Promtool should support openmetrics, next to the text format.

Maybe via --format=openmetrics

[ide-rea]

Hi, does this mean check openmetrics format like check prom text format, could you tell me?

[roidelapluie]

This issue is to add support for promtool check metrics --format=openmetrics

[ide-rea]

Thanks, i would like to try if not anybody is working on this.

[ide-rea]

Hi, i'm a little confused about the check rule. Do we parse the text wire openmetrics format into prometheus MetricFamily, and then encoded the metrics into bytes stream, at last use promlint package to do the check? need your help, thanks :) @roidelapluie

[roidelapluie]

This issue would require a openmetrics text parser in go, which does not exist at the moment. We only have a textformat parser in go.

[roidelapluie]

Here is the textparser in go: https://github.com/prometheus/common/blob/main/expfmt/text_parse.go We should have one openmetrics parser in go for this issue. It should be developed next to the text parser, in the prometheus/common repository.

[ide-rea]

Thanks, i'm understanding the issue better!

[jyz0309]

Is this Issue still valid and can I try it? :)

[machine424]

I think so, especially that prometheus supports back filling from openmetrics https://github.com/prometheus/prometheus/pull/8084

[beorn7]

Hello from the bug scrub!

@jyz0309 are you still willing to work on this? We'll happily assign this issue to you (or to others that want to help with it).

Note that it requires an implementation of an OpenMetrics parsers in https://github.com/prometheus/common/tree/main/expfmt , so it's a bit of work and maybe not as easy as it looks.

[jyz0309]

@beorn7 Yes, I am willing to try this issue, I think I need to implement an OpenMetrics parser and merge in expfmt firstly then use it to support openmetrics in promtool.

[jyz0309]

@beorn7 Hello! I want to ask sth about the parser in expfmt, I am implementing the OpenMetrics parser in expfmt and I found that in client_model still have not support info, stateset types, should I add these to protobuf file first or just unsupported these two type firstly (I found that the encoder also unsupported these type yet)?

[beorn7]

Yeah, good question.

So the source of dissonance here is that the encoders and parsers in https://github.com/prometheus/common/tree/main/expfmt are all based on https://github.com/prometheus/client_model , which in turn represents the data model behind the classic Prometheus text format. (OpenMetrics in fact has its own protobuf spec here.)

As the encoder is also just encoding from the classic Prometheus protobuf, let's do what you said above, i.e. implement a parser that supports everything we can easily put into the classic Prometheus protobuf. We can later decide if we want to convert info and stateset into other metrics (which is essentially what Prometheus itself is doing right now upon ingestion) or add support for it into the classic protobuf or port the whole shebang to the OpenMetrics protobuf (which isn't that different after all).

[jyz0309]

https://github.com/prometheus/common/pull/669 @beorn7 I have implement OpenMetrics parser in expfmt in this PR, PTAL, thanks :)