expfmt: Implement OpenMetrics generation about common

[beorn7]

This has to take into account special float formatting. (An integer number that is actually typed as a float always has to end on .0 or has to contain an e. Note that histogram buckets are types as int.)

Also, OpenMetrics suffers from name collisions (due to additional "magic" suffixes of the metric name: _created, _total). The generator has to detect those collisions to avoid creating invalid output.

[brian-brazil]

An integer number that is actually typed as a float always has to end on .0 or has to contain an e. Note that histogram buckets are types as int.

As currently drafted this only strictly applies to le and quantile labels - and even that is not finalised as to whether it'll be a SHOULD or MUST. I'd hope the Go client would be a good example that others can follow though, considering it'll likely be the most used.

[beorn7]

Hmm, I would have thought it's also quite important for sample values. Following line of thought:

• The unambiguous marking of int vs float is meant for consumers that, unlike Prometheus, distinguish between int and float as a sample value.
• Those consumers will register a newly appearing time series as one or the other, depending on the first sample. Let's say it's 1.234, i.e. float.
• If then suddenly a sample comes in that reads 1 (instead of 1.0), they will be confused.
• The other way round is probably worse: Get an int first, filing it as an int series, and then suddenly floats come in.

In contrast, I would see le and quantile labels as unproblematic because they are always floats. And since we have no proven way of unambiguous float formatting (see OpenObservability/OpenMetrics#129 ), those labels have to be sanitized be the consumer anyway before series identity is determined. (In different news, a more advanced consumer, including possibly a future version of Prometheus, will not treat the quantiles and buckets as separate series anyway, so those labels aren't really labels anymore, and the whole problem disappears.)

[brian-brazil]

If then suddenly a sample comes in that reads 1 (instead of 1.0), they will be confused.

But must handle it, as while it'd be not recommended each output is still individually valid - and can happen for good reasons such as due to a new binary release.

The other way round is probably worse:

Yeah, that's more of a problem. Same considerations apply though.

I'd treat it as a compression hint more than anything. We should be nice to consumers where practical though - especially given the prominence of client_golang.

so those labels aren't really labels anymore, and the whole problem disappears

That's the dream, once we manage to get most other monitoring system vendors able to understand our style of histograms.

[beorn7]

Basic OpenMetrics generation is implemented now.

I'll update the issue description to include the remaning TODOs. (We could break them into separate issues and close this one if that's preferred.)

[brian-brazil]

This issue is fine, the OP is nicely organised.

We also need to drop _sum when there's negative buckets.

[beorn7]

We also need to drop _sum when there's negative buckets.

It would be a pity if OM really went down that road. See OpenObservability/OpenMetrics#143 for a better solution.