Naming convention for OpenTelemtry properties on Quarkus

[Bruno Baptista]

Hi all,
I've been working on the upcoming OpenTelemetry (OTel) Autoconfiguration on Quarkus.

This will allow, among other things, the full support of the OTel Java SDK properties listed in here: https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/README.md

Their naming convention for the system properties is:

otel.*

Example: otel.traces.exporter

The equivalent environment variables are:

OTEL_*

Example: OTEL_TRACES_EXPORTER

This aligns quite well with the Quarkus established practices, however we usually use the "quarkus" prefix on our properties. 

What do you guys think of using these properties as defined by OTel and not add the common "quarkus" prefix to them?

Meaning we would configure OTel system properties like this:

OPTION A: otel.traces.exporter

And not like this

OPTION B: quarkus.otel.traces.exporter

If we need some particular telemetry related property that is unique to quarkus we would still add our prefix.

Any thoughts on this?

Cheers!

Bruno Baptista  

https://twitter.com/brunobat_

https://redhat.com

[George Gastaldi]

Hey,

There is a `prefix` attribute in the @ConfigMapping annotation that can be set to any value, so I believe this is possible.

Best Regards,

George Gastaldi

Principal Software Engineer

Red Hat

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/6da999bd-bb95-4cc1-a0fe-6708840fba27n%40googlegroups.com.

[Roberto Cortez]

Hi Bruno,

Please, use the quarkus namespace. By convention, all of the Quarkus core extensions use it, and users are already used to it. If we start adding core extensions that do not follow this rule, it will be harder for users to discover them.

Also, we do provide different behavior (like validation, build time / runtime, etc) that the original otel properties do not support.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/e6f1dd98-5d6c-4c0d-a3ca-aa306be18bea%40Spark.

[Georgios Andrianakis]

On Tue, Aug 30, 2022 at 2:06 AM 'Roberto Cortez' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

Hi Bruno,

Please, use the quarkus namespace. By convention, all of the Quarkus core extensions use it, and users are already used to it. If we start adding core extensions that do not follow this rule, it will be harder for users to discover them.

+100

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/55F43EA3-B534-4FEB-A385-947048C71A03%40yahoo.com.

[Max Rydahl Andersen]

+10000 on using quarkus prefix.

There is a reason we use quarkus prefix. We want the ability to have different defaults and simplify configuration;
even not enabling every option as some frameworks has features not necessarily fitting in a build time / kubernetes/cloud native world.

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DcqBVMvu2%2BPTiCGcqNOLekiZS62QhC_eVTE%2B-vooGzwA%40mail.gmail.com.

[Bruno Baptista]

Thanks to all for the feedback.

In this case we change some defaults and validate the properties. That's fine.

If we use the "quarkus" prefix on them, how should we name properties not in the standard that are exclusive to quarkus?

Cheers.

Bruno Baptista

https://twitter.com/brunobat_

https://redhat.com

You received this message because you are subscribed to a topic in the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/quarkus-dev/cBbGFUEtERg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/24A3E678-42D0-4443-80E9-29E034DEB0F9%40redhat.com.

[Max Rydahl Andersen]

On 30 Aug 2022, at 11:08, Bruno Baptista wrote:

> Thanks to all for the feedback.
> In this case we change some defaults and validate the properties. That's
> fine.
> If we use the "quarkus" prefix on them, how should we name properties not
> in the standard that are exclusive to quarkus?

since they have a the prefix already you don't need to give them specific names.

We do try and use the same names if they are semantically equivalent.

/max

>>> Red Hat <https://www.redhat.com/>
>>>
>>> <https://www.redhat.com/>

>>> <https://groups.google.com/d/msgid/quarkus-dev/6da999bd-bb95-4cc1-a0fe-6708840fba27n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/quarkus-dev/e6f1dd98-5d6c-4c0d-a3ca-aa306be18bea%40Spark
>>> <https://groups.google.com/d/msgid/quarkus-dev/e6f1dd98-5d6c-4c0d-a3ca-aa306be18bea%40Spark?utm_medium=email&utm_source=footer>
>>> .

>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/quarkus-dev/55F43EA3-B534-4FEB-A385-947048C71A03%40yahoo.com
>>> <https://groups.google.com/d/msgid/quarkus-dev/55F43EA3-B534-4FEB-A385-947048C71A03%40yahoo.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DcqBVMvu2%2BPTiCGcqNOLekiZS62QhC_eVTE%2B-vooGzwA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DcqBVMvu2%2BPTiCGcqNOLekiZS62QhC_eVTE%2B-vooGzwA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Quarkus Development mailing list" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/quarkus-dev/cBbGFUEtERg/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/quarkus-dev/24A3E678-42D0-4443-80E9-29E034DEB0F9%40redhat.com

>> <https://groups.google.com/d/msgid/quarkus-dev/24A3E678-42D0-4443-80E9-29E034DEB0F9%40redhat.com?utm_medium=email&utm_source=footer>
>> .
>>

/max
https://xam.dk/about

[Roberto Cortez]

I believe it is acceptable to use quarkus.otel for our specific configuration.

I guess the concern is about clashing names between Quarkus and OTel. The chance should be slight, and if it happens, we have to figure out the behavior difference first and adjust.

Cheers,
Roberto

> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/2E164ED9-30CA-41B8-954F-03E763771FC5%40redhat.com.

[Erin Schnabel]

So. OTel is used across languages and frameworks. Consistency for OTel configuration is beyond the bounds of just quarkus.

From what I've been seeing, people expect OTel to look/feel like Otel, regardless of what language they are in.

So which is more important: familiarity for people using OpenTelemetry universally? Or familiarity with Quarkus... They are two different things.

While we have a quarkus convention, I'm really on the fence w/ otel .. because requiring the quarkus prefix makes quarkus unique...

In many cases, people will be used to configuring agents for other Java runtimes.. I would love for those options to be usable directly, without them having to read the quarkus docs to find the quarkus specific variant... 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/32800390-2CBD-4D3E-9ADF-9EAB4338C873%40yahoo.com.

[Guillaume Smet]

You can say that for a lot of components we are using (MicroProfile comes to mind, they have their own config namespace, Hibernate ORM has its own too, RESTEasy Classic... and I'm pretty sure that will be the same for each well known component we are using).

If we did that for every component, we would end up with a big mess.

So why not support both if you think it's important. But I think we need to provide some consistency across Quarkus.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJwjk9yeKBeL_G8AZ7u7728XiwSi4epAEK3PoQXVskZNYNr7Lg%40mail.gmail.com.

[Phillip Kruger]

Why not support both ? In MP users can still use the property as defined by the MP Spec, but we also map the key to a quarkus one

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9TSw1nRtw0hT7cVnQKN8ehazw83-kN4n1uL0%2BH0vKR2A%40mail.gmail.com.

[Max Rydahl Andersen]

On 31 Aug 2022, at 0:52, Phillip Kruger wrote:

Why not support both ? In MP users can still use the property as defined by
the MP Spec, but we also map the key to a quarkus one

correct - it is an advantage that we have quarkus.* to enable
differentiation to i.e. NOT support a feature that somehow is not feasible/viable to support in Quarkus buildtime/native world.

/max

https://groups.google.com/d/msgid/quarkus-dev/32800390-2CBD-4D3E-9ADF-9EAB4338C873%40yahoo.com
.

--

You received this message because you are subscribed to the Google Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CAJwjk9yeKBeL_G8AZ7u7728XiwSi4epAEK3PoQXVskZNYNr7Lg%40mail.gmail.com
<https://groups.google.com/d/msgid/quarkus-dev/CAJwjk9yeKBeL_G8AZ7u7728XiwSi4epAEK3PoQXVskZNYNr7Lg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

--
You received this message because you are subscribed to the Google Groups
"Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9TSw1nRtw0hT7cVnQKN8ehazw83-kN4n1uL0%2BH0vKR2A%40mail.gmail.com
<https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9TSw1nRtw0hT7cVnQKN8ehazw83-kN4n1uL0%2BH0vKR2A%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAEyd7D7rzDav%3DX8S5Xu1rr3WmUESwM9N2Y97Ork1TDKeDVHJog%40mail.gmail.com.

/max
https://xam.dk/about

[Roberto Cortez]

OTel has its own Configuration mechanism.

Their public API, only allows us to pass in defaults, and they will always override those values by reading otel. properties from system or env, which would be super confusing for our users. It means that even if we have an .otel property in our Config system with a MAX ordinal, system properties or env variables would still override the value when configuring OTel. I think this would be super confusing because that is not how our Config works, so my recommendation is to always use the quarkus namespace.

They previously had an API that allowed us to configure things directly, but they removed that. I’ve tried to have them keep that, but they were not convinced:

https://github.com/open-telemetry/opentelemetry-java/pull/4002

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/BC658080-E248-41F7-B542-30443FCBFA1F%40redhat.com.

[Bruno Baptista]

Hi
It seems we have a large majority of supporters and reasons to use the quarkus namespace.

Supporting the 2 namespaces for the same function, with and without the quarkus namespace, will add noise, a priority confusion, unneeded additional complexity and most certainly some insidious bugs. 

We are going to mirror the behaviors and documentation of all the OTel configs anyway. No need for the users to go to the OTel side documentation page.

On properties that are specific to Quarkus, or default values that we are changing will be highlighted. 

Cheers

Bruno Baptista

https://twitter.com/brunobat_

https://redhat.com

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/D94F030B-85DF-459E-B6EA-1E3B9D1EDC7D%40yahoo.com.

[Bruno Baptista]

Hi all!
It looks like this choice of using the quarkus namespace prefix has bitten us back.

Because we are not using the default OTel property names we need to create a custom prefix support in the openshift operator: https://github.com/open-telemetry/opentelemetry-operator/issues/1962 

I imagine other providers will have to do the same.

Cheers.

Bruno Baptista

https://twitter.com/brunobat_

https://redhat.com

[Max Rydahl Andersen]

> Hi all!
> It looks like this choice of using the quarkus namespace prefix has bitten
> us back.
> Because we are not using the default OTel property names we need to create
> a custom prefix support in the openshift operator:
> https://github.com/open-telemetry/opentelemetry-operator/issues/1962

I'm missing something here - what is the openshift operator trying to do here? generically apply opentel settings to any application supporting open telemetry?

The way I commented below on use of quarkus prefix was that we use quarkus space to expose just enough of the config that works and allows us to limit the configurability AND allow for tooling to be smarter. Also to ensure there is a clear way to document what is build time and what is not.

This other usecase of supporting a generic configuration of opentel is why it was suggested to support both - since they are different usecases?

Having ability to put prefix seems useful to me IMO to avoid namespace collisions; but also - couldn't we have support for mapping the two sets?

> I imagine other providers will have to do the same.

What other providers do you mean here?

/max

> Cheers.
> Bruno Baptista
> https://twitter.com/brunobat_
> https://redhat.com
>
>

>>> correct - it is an *advantage* that we have quarkus.* to enable

>>> https://groups.google.com/d/msgid/quarkus-dev/BC658080-E248-41F7-B542-30443FCBFA1F%40redhat.com
>>> <https://groups.google.com/d/msgid/quarkus-dev/BC658080-E248-41F7-B542-30443FCBFA1F%40redhat.com?utm_medium=email&utm_source=footer>

>>> .
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Quarkus Development mailing list" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/quarkus-dev/cBbGFUEtERg/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/quarkus-dev/D94F030B-85DF-459E-B6EA-1E3B9D1EDC7D%40yahoo.com
>>> <https://groups.google.com/d/msgid/quarkus-dev/D94F030B-85DF-459E-B6EA-1E3B9D1EDC7D%40yahoo.com?utm_medium=email&utm_source=footer>

>>> .
>>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAPC_VGk4AfhE%2BPtTDAG0EwRxjwJbn0GbFJreApHQktmMYnv8Zw%40mail.gmail.com.

[Bruno Baptista]

Our apps must not be configured with the default OpenTelemetry properties, but with the ones using the prefix.

The Operator must be aware of this, and it isn't... In practice, it only supports apps using the OTel Agent, which Quarkus doesn't use.

Since I wrote the email I think using our own namespace is better, but I will need to propose some changes in the OTel SDK, to make sure we don't get unintended property collisions. 

Cheers.

Bruno Baptista

https://twitter.com/brunobat_

https://redhat.com