On Mon, May 27, 2024 at 10:07 AM 'George Robinson' via Prometheus
Developers <prometheus-developers@googlegroups.com> wrote:
> Hi! I worked with Björn and Josh to add support for UTF-8 in Alertmanager,
> and I thought I would share my opinion on this matter as we had to solve
> similar problems there.
>
> I'm with Bryan and Fabian on the dot operator. If dot is all that's needed
> to support the OTel character set for metric names in Prometheus, and we
> don't expect further relaxations of this character set, then I think we
> should add it to Prometheus. We can then defer the problem of supporting
> UTF-8 in metrics names and how it would work with the existing PromQL
> grammar.
>
> I also wouldn't worry about future use of dot as a syntactic sugar for
> label matchers or native histograms. I personally don't think it adds much
> to PromQL over the more verbose foo{job="bar"} or
> histogram_sum(sum(request_duration_seconds)), and I would argue it makes
> PromQL more difficult to learn.
>
>From what I've heard so far, I would tend to agree with all that. However,
I'd like to make sure that Björn also weighs in on the dot character
question, since he was the main person raising concerns about it in the
past. CC-ing him here :)
On Björn's suggestion of __name__, I don't share Julius' concerns. In fact,
> I think it's quite nice because:
>
> 1. You can and sometimes have to use __name__ in Prometheus if the metric
> name conflicts with a reserved word. It is also a documented feature in
> Prometheus and extending it for metric names with UTF-8 seems very sensible
> to me.
>
While this is technically true, I've never seen such a reserved-word
collision in practice, and the problem would only occur for a few reserved
words, like "on"/"ignoring", but e.g. not for just "rate" or "by" or "sum"
etc. when they are grammatically used as a metric name. Other than that,
you only ever need to know about "__name__" if your metrics are structured
weirdly and you need to do regexes against them or if you're doing
admin-level queries.
> 2. In TSDB, the metric name is just a label anyway, is it not? If
> anything, once you understand how Prometheus stores metrics, querying a
> metric using __name__ feels more natural than the current PromQL grammar
> where it is separate from all other label matchers.
>
Yeah, I think it's good for people to know that it's just a special label,
but you should almost never need to access "__name__" unless your metrics
are structured badly (encoding things in the metric name that should really
be in a label) or if you are doing admin-level Prometheus stuff (e.g.
figuring out which dimensional groupings produce how many time series in
your Prometheus server). So I think requiring power users to use "__name__"
for those exceptional queries is acceptable, but requiring it for just
every-day normal user queries would make the query language less
approachable.
However, I'm not convinced that we should adopt the short {="metric_name"}
> or optional = as in {"metric_name"}. In this case I think consistency and
> uniformity of the grammar is more important than verbosity.
>
Yeah, I'm split on that. On one hand, I don't want people to have to type
the internal "__name__" label, on the other hand I like things to be
explicit as well. Maybe one could have a special string syntax (e.g.
prefixed somehow like in Python) for metric names that doesn't collide with
our existing strings, so you could just write something like:
m"some.metric.name.with.dots"{foo="bar"}
I'm not sure if I like that much more though 😅
However, this is all irrelevant if we choose to accept dot anyway :)
>
As long as people stick to OTel conventions at least, yeah :)
Cheers,
Julius
>
> George
>
>
>
>
> On Friday, May 24, 2024 at 2:44:17 PM UTC+1 Julius Volz wrote:
>
>> 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 <fab...@fstab.de> 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 <bjbo...@gmail.com>
>>> 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 <juliu...@gmail.com> 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 prometheus-devel...@googlegroups.com.
>>>> 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 prometheus-devel...@googlegroups.com.
>>>> 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 prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/a402cc06-651d-4a32-950b-b58fa33d6775n%40googlegroups.com
> <https://groups.google.com/d/msgid/prometheus-developers/a402cc06-651d-4a32-950b-b58fa33d6775n%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 prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowjiXC7VZjait%3Dgwe%3D8QgUr6pYs%2B3ZXiCGti9-uTVb5Lg%40mail.gmail.com.
