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.
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.
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.
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.
However, this is all irrelevant if we choose to accept dot anyway :)
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.
