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/ZlZX4SJpb/ajSLkd%40mail.rabenste.in.
