The results of Otel-Prometheus interoperability are out, which is probably relevant to the discussion here (specially the questions regarding UTF-8)
https://github.com/open-telemetry/sig-end-user/tree/main/end-user-surveys/otel-prom-interoperability On Wed, May 29, 2024 at 12:41 PM Julius Volz <[email protected]> wrote: > Hah, I knew it would be a good idea to check with Björn :D Thanks Björn, > that's a great write-up! > > Yes, that also convinced me about not allowing the dot as a normal > character for now. Lots of good arguments, but number 3 actually resonates > the most with me - why allow two different separator characters if they > have no semantic difference (no true namespacing). > > On Wed, May 29, 2024 at 3:26 PM 'George Robinson' via Prometheus > Developers <[email protected]> wrote: > >> Thanks Björn for writing this up, and also writing up Collected reasons >> why Prometheus doesn't allow dot as a regular character in metric and label >> names <https://groups.google.com/g/prometheus-developers/c/4ri-xn7ynK4>. >> I think it adds a huge amount of value for people looking to participate in >> discussion! Having read through it all I withdraw my original support for >> just adding dot to metric names. There are a lot of considerations I did >> not know about that I agree with thanks to your document. >> >> On Tuesday, May 28, 2024 at 11:17:10 PM UTC+1 Bjoern Rabenstein wrote: >> >>> I'm trying to keep things short, as all of this had been discussed >>> at length before. >>> >>> WRT "how to explain UTF-8 support to users": I actually don't think >>> this is a huge problem. I would frame it "this is like file >>> names". You can use blanks and slashes in Unix file names, and if you >>> do, it requires weird quoting or escaping, but that's not a huge >>> problem in practice. People just don't use them if they care. And if >>> they have to interact with other file sources, where blanks are >>> common, they cope. And yes, that means that names from OTel semantic >>> conventions will always be considered weird, but that's a problem of >>> OTel, not all the other languages where a dot has a special >>> meaning. Segue to the next paragraph... >>> >>> WRT the dot in OTel semantic conventions: Personally, I'm more >>> convinced than ever that it was a grave mistake to use dots in the >>> semantic conventions. I understand the history thereof, but the moment >>> that OTel self-declared as the overarching standard for all kind of >>> telemetry, they should have realized that using a character that has a >>> special meaning or is even an operator in sooooo many languages is a >>> really really bad idea. This is not just PromQL specific. Originally, >>> I thought it's infeasible to change the semantic conventions at this >>> point, but by now, that's exactly what I think OTel should do. If the >>> dot were an actual operator in OTel (let's say a separator of actual >>> 1st class namespaces) rather than just a convention within a >>> technically opaque string, I could see some merit. But as it is not, >>> it's just annoying and has no benefits whatsoever. >>> >>> Despite having said all of that, I don't realistically expect that >>> OTel is going to change the semantic conventions. So next question is >>> how to deal with it. There are many reasons why it's a bad idea to >>> allow the dot in Prometheus metric names, most of them weren't >>> mentioned in this thread. I won't enumerate them all again. We can do >>> that if we really want to open that can of worms again. Segue to the >>> next paragraph... >>> >>> In all the discussions we had before, my impression was that the >>> consensus (in the spirit of RFC 7282) was to not add the dot to the >>> characters that don't require quoting. As the saying goes, in OSS, a >>> "no" is temporary and a "yes" is forever. So we can re-open this >>> debate as often as anyone wishes. If the result is different at some >>> point in the future, so be it. It's unlikely that I will change my >>> mind (in fact, as alluded to above, I'm more convinced than ever that >>> Prometheus should resist the urge). But that doesn't necessarily >>> prevent an RFC-7282-style consensus. (Or we could also just have a >>> vote, like in the old days, although that should be a last resort.) >>> Despite the opinions expressed so far, I would doubt that I'm the only >>> one who will be opposed. >>> >>> Julius has previously described quite nicely how OTel conventions and >>> practices creep into the Prometheus ecosystem, undermining original >>> properties of Prometheus as "simple, light-weight, and >>> opinionated". The whole quoting syntax that opened this thread is for >>> me a way of allowing what OTel needs but also of containing the damage >>> and keep things in spirit for normal Prometheus users. Maybe another >>> thing to include when explaining the syntax to normal Prometheus >>> users. >>> >>> -- >>> Björn Rabenstein >>> [PGP-ID] 0x851C3DA17D748D03 >>> [email] [email protected] >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Prometheus Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/d14d59cf-204b-4215-afb8-3b5adee96be4n%40googlegroups.com >> <https://groups.google.com/d/msgid/prometheus-developers/d14d59cf-204b-4215-afb8-3b5adee96be4n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxypJRtxY%2B_rCspTEjvZi%3D2LD0Gn75f_vLKNfM-ReMPSQ%40mail.gmail.com > <https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxypJRtxY%2B_rCspTEjvZi%3D2LD0Gn75f_vLKNfM-ReMPSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAJqZosxwoWTqgLfEmhEyMjvidW6-hFxJzzz3ev3A%3D4ZnV_deDQ%40mail.gmail.com.
