OpenTelemetry SDK autoconfiguration ignores OTEL service name in favor of Quarkus app name

[michalvavrik]

Describe the bug

With #30033 I expected autoconfiguration work for properties listed here https://github.com/quarkusio/quarkus/blob/main/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/config/OTelFallbackConfigSourceInterceptor.java#L85 and OTEL documentation says that otel.service.name should have preference over otel.resource.attributes. However, Quarkus OpenTelemetry extension creates Tracer resource directly and is using Quarkus application name (or artifact if not available)

quarkus/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/tracing/TracerRecorder.java

Line 52 in 43a5358

ResourceAttributes.SERVICE_NAME, serviceName,

quarkus/extensions/opentelemetry/deployment/src/main/java/io/quarkus/opentelemetry/deployment/tracing/TracerProcessor.java

Line 158 in 43a5358

return new TracerResourceBuildItem(recorder.createResource(Version.getVersion(), serviceName, serviceVersion));

Expected behavior

Quarkus documentation says otel.service.name should have priority

quarkus/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/config/runtime/OTelRuntimeConfig.java

Line 52 in 43a5358

* Specify logical service name. Takes precedence over service.name defined with otel.resource.attributes

Actual behavior

Quarkus application name is used.

How to Reproduce?

Define otel.service.name and check traces (I'm using Jaeger). IMHO it's straight forward, but ping me if you really need one.

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

999-SNAPSHOT

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @brunobat (opentelemetry), @radcortez (opentelemetry)

[brunobat]

otel.service.name is not even being mapped. We use the standard quarkus.application.name for quarkus.

Somewhere around here:

quarkus/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/OpenTelemetryProducer.java

Line 86 in 43a5358

Resource consolidatedResource = existingResource.merge(

We should map otel.service.name into the oTelConfigs and agree on a priority for it, in runtime. Something like:

quarkus.application.name > otel.service.name > otel.resource.attributes

Test for the resource:

quarkus/extensions/opentelemetry/deployment/src/test/java/io/quarkus/opentelemetry/deployment/OpenTelemetryResourceTest.java

Line 54 in 3e6b2a5

assertEquals("authservice", server.getResource().getAttribute(AttributeKey.stringKey("service.name")));

[michalvavrik]

otel.service.name is not even being mapped. We use the standard quarkus.application.name for quarkus. We should map otel.service.name into the oTelConfigs and agree on a priority for it, in runtime. Something like:

I appreciate feedback @brunobat , but I am not sure I understand above-mentioned. If it is not even being mapped, what is this property?

quarkus/extensions/opentelemetry/runtime/src/main/java/io/quarkus/opentelemetry/runtime/config/runtime/OTelRuntimeConfig.java

Line 52 in 43a5358

* Specify logical service name. Takes precedence over service.name defined with otel.resource.attributes

It exactly matches pattern otel.service.name plus quarkus. prefix. And it's description mentions opposite priorities, loose interpretation:

otel.service.name > quarkus.application.name > otel.resource.attributes

I think what you meant to say is that we simply need to use it somewhere around the line you linked to, correct?

[brunobat]

yeah, it is mapped. I just forgot about it. Sorry.
The current property is mapped like that: otel.service.name > quarkus.application.name > otel.resource.attributes... I have no strong feelings in relation to the first 2 priorities.
Saying this...
This might be a mapping failure at the OTelFallbackConfigSourceInterceptor, otherwise I'm not sure what we are doing wrong because the resource prop and the config props are being sent to the OTel SDK that interprets them...
A new IT test should clear things out.

[michalvavrik]

Thanks, makes sense, I'll look at this next week unless someones quicker.

[geoand]

@michalvavrik are you still planning on tackling this one?

[michalvavrik]

Thanks for the reminder, I'll take care of it this week.