Optionally add OM unit

[vesari]

This PR adds support for unit for Open Metrics. It is ready for review, but not ready to merge (see my long comment below). Fixes #684.

[ArthurSens]

Hey @vesari , just passing by to ask if there is anything we could do to unblock you 👋

[vesari]

Hey @vesari , just passing by to ask if there is anything we could do to unblock you 👋

@ArthurSens hello! I think I'm just using a Go version which is too new, I plan on fixing that later today. Thanks a lot for checking on me, much appreciated! :)

[vesari]

@ArthurSens hello again! Here are a few considerations to give you some insight about what I’ve done here and why.
I had to upgrade Go in the GitHub workflows so that the version is at least 1.21, as this is needed by common 0.50.0 which, as you know, contains the necessary implementation for unit. I also changed the Makefile and the go.mod and main.go files in the tutorial folder accordingly. I have not touched the .bingo file but I guess the version should be upgraded there too.
However, Tests(1.20) is still expected to run among the checks, and, as you can see, just hangs, but I suppose that’s because of the repo settings, so I’ll need your help there.

The lint was failing on a supposedly unused test function unrelated to my changes (withDebugMetrics), so I removed it. Let me know if I should instead just have the lint ignore it.

I made the changes needed where an OM format can be passed to expfmt.NewEncoder, and also all the others stemming from the field Unit being added to the type prometheus.Desc. In some cases, I chose to populate this field with the unit which was already included in the metric family name, but I could have also just put an empty string, and I’m not sure what the preferred behaviour would be or if it doesn’t make any difference. I’m talking especially about the various collectors files, like prometheus/collector/dbstats_collector.go , prometheus/go_collector.go or prometheus/go_collector_latest.go etc. I’d be grateful if you could advise me on this.

Also, so far I haven’t added any new tests to promhttp/http_test.go, considering not even the EnableOpenMetrics option has been tested there. Let me know if I should.

Lastly, I happened to push a lot of commits, let me know if you want me to rebase and squash them.

As per usual, many thanks for your time and help! :)

[ArthurSens]

Oh sorry for the silence here, somehow I missed your last comment.

I had to upgrade Go in the GitHub workflows so that the version is at least 1.21, as this is needed by common 0.50.0 which, as you know, contains the necessary implementation for unit.

Yeah, that's a problem actually. We promise support for the 3 latest go versions, so we can't bump our go version to 1.21 until mid-August when go 1.23 is released. I've started conversations about how we can improve this situation with common.

The lint was failing on a supposedly unused test function unrelated to my changes (withDebugMetrics), so I removed it. Let me know if I should instead just have the lint ignore it.

This is another problem that I've been delaying for way too long 😬 From my understanding it doesn't block PRs though. But anyway, I'll try to get back to this soon, no need to remove it now :)

---

Regarding the changes that are related to OpenMetrics units, I haven't taken a deep look yet 😬. I'm mostly concerned with enabling the PR first and will review the changes once we solve all the blockers

[vesari]

Thanks a lot for the detailed update! Much appreciated

[ArthurSens]

Hi @vesari, all blockers have been resolved finally :)

The unused function is now used, and we can update prometheus/common without giving up support of go 1.20. If you rebase your PR it should be fine :)

[ArthurSens]

In #1408, we're changing a bit the structure of the HandlerOpts regarding OpenMetrics functionality. We'll probably want something similar here

[vesari]

@ArthurSens I made some changes to my code accordingly, but I think it would be better for your PR to be merged before mine, as yours has already been approved and also because in yours you explain the rationale behind the new HandlerOpts struct and what options to prefer. I can then take it from there and finish mine. What do you think? :)

[vesari]

Awesome! Thank you very much! I'm on it.

[vesari]

@ArthurSens , I've marked this as "ready for review", but I'm still assuming your PR should be merged first?