I would love to understand how to come to a decision as a project in a way that will preclude regular second-guessing. We went through the proposal process (https://github.com/prometheus/proposals/blob/main/proposals/2023-08-21-utf8.md) so I though the question of both "if" and "how" were already closed.
On Wednesday, June 5, 2024 at 12:07:48 PM UTC-4 Fabian Stäber wrote: > Thanks a lot for sharing! > > So, is the prefered solution to keep things as they are, i.e. keep > replacing dots with underscores? > > > why allow two different separator characters if they have no > semantic difference (no true namespacing). > > This argument seems to resonate with the Prometheus team. If this is the > main concern, we don't solve it by allowing dots in quotes. We solve this > by replacing dots with underscores. > > From the survey it looks like most users prefer the current naming scheme > as well: > > [image: screenshot_2024-06-05_18:04:05_908234003.png] > [image: screenshot_2024-06-05_18:04:14_304430186.png] > Shall we just drop the idea of adding UTF-8 support? > > Fabian > > > > > On Wed, Jun 5, 2024 at 5:31 PM Arthur Silva Sens <[email protected]> > wrote: > >> 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 >> >> <https://groups.google.com/d/msgid/prometheus-developers/CAJqZosxwoWTqgLfEmhEyMjvidW6-hFxJzzz3ev3A%3D4ZnV_deDQ%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/87d6bd74-bbfc-47e8-b7fb-edb95fc9d567n%40googlegroups.com.
