Yeah, that's true, that would help a lot already. Maybe it's time to open up the dot after all. I know we've kept it reserved for "reasons" (first as a potential "job" label separator, then later for other potential future ideas like ".sum" / ".count" for native histograms), but maybe it's worth finally using it for this. I know Björn has the strongest opinions on the dot :)
On Fri, May 24, 2024 at 1:31 PM Fabian Stäber <[email protected]> wrote: > What Bryan said. OpenTelemetry's semantic conventions don't use all of > UTF-8. They are restricted to the same character set as Prometheus plus the > dot. > If we simply allow the dot, we cover all of OTel's semantic conventions > for metric names and label names. > I don't care if custom metrics that use arbitrary UTF-8 characters require > a weird escaping syntax. > The goal should be to make OpenTelemetry's semantic conventions work > nicely with Prometheus. > > Fabian > > On Fri, May 24, 2024 at 11:52 AM Bryan Boreham <[email protected]> > wrote: > >> I think we should allow dot (.) in names without quoting. >> >> It gives up a possible operator, but makes the syntax nicer for the vast >> majority of people who need a change. >> >> Bryan >> >> On 24 May 2024, at 10:00, Julius Volz <[email protected]> wrote: >> >> >> Hi, >> >> While others are figuring out how to add UTF-8 support and other OTel >> compatibility functionality to Prometheus, my brain has been trying to >> figure out what all of this will mean for the normal Prometheus user, how >> we should explain this new optionality in Prometheus, and what we should >> recommend with regards to UTF-8 usage outside of the OTel compatibility >> scenario. >> >> What (literally) keeps me up at night the most is the new selector syntax >> that metric names with previously illegal characters will now require: >> https://docs.google.com/document/d/1yFj5QSd1AgCYecZ9EJ8f2t4OgF2KBZgJYVde-uzVEtI/edit#heading=h.yxv3hzhog2l2 >> . >> >> In this proposal, Björn did the best he could given the difficult >> situation that OTel compatibility support push puts us in, and I also don't >> have better ideas for nicer syntaxes. However, it looks like all current >> selector syntax suggestions require putting the metric name not only in >> quotes, but also within the curly braces, and possibly even introducing new >> (IMO) very odd short-hand syntaxes for it. >> >> Given that I think this new selector syntax is very unelegant, inferior, >> and confusing (harder to type, harder to read and understand intuitively) >> compared to Prometheus' really clean and nice existing selector syntax that >> we've had for over 10 years, how should we approach UTF-8 support when >> explaining it to users? Should we say, "Yes, the Prometheus data model now >> allows any UTF-8 characters in metric names, but you should really ignore >> this fact completely and stick to the old character set, unless you have to >> deal with UTF-8 for the purpose of OTel metrics because otherwise your >> PromQL will start looking really weird"? Or do we not give any >> recommendations around it at all? >> >> I just fear that UTF-8 characters will start creeping in everywhere >> because people see that it's supported. And then all users will eventually >> just have to start using the new syntax for everything, because "that's the >> one that always works", and because they didn't even know or think about >> that fact when they were creating their metrics. In any case, all this will >> require a whole lot of new explanations for every new Prometheus user, and >> the same is true for some of the other OTel features. >> >> There's other things that worry me about UTF-8 support and OTel support >> in general, but the selector syntax and what this will ultimately do to >> Prometheus users down the road is the main one. Any opinions on how we >> should advertise this to the regular (non-OTel) Prometheus user going >> forward? >> >> Cheers, >> Julius >> >> -- >> 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%2BT6YowuTe6tLp1N0jEQc5zhAQE0RDpdME4tP4m-uXEmRKqwPA%40mail.gmail.com >> <https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowuTe6tLp1N0jEQc5zhAQE0RDpdME4tP4m-uXEmRKqwPA%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/C96DD934-9A56-4A1E-B1CA-E45AAD1B1E41%40gmail.com >> <https://groups.google.com/d/msgid/prometheus-developers/C96DD934-9A56-4A1E-B1CA-E45AAD1B1E41%40gmail.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%2BT6YoyUMccMsxR15ppMJRvU7pC2btPVTL9gZqO41qzxfpZSDg%40mail.gmail.com.
