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.
