Span Naming - New HTTP Semantic Behavior http.url v/s url.full

[zoomingrocket]

Expected behavior

We are upgrading from Java Agent v3.4.19 to v3.7.2, and one of the critical changes was adopting new HTTP Semantics from Otel Our request Span naming was leveraging http.url to extract path, and then set the span name as "HTTPMethod HTTPPath"

Actual behavior

With v3.7.2 we shifted to url.full attribute to extract the path, but noticed that in certain spans, the path is either missing entirely or is partial We explored leveraging directly url.path attribute for span name instead of extraction but similar partial behavior. If we revert back to http.url with v3.7.2 our original behavior for Span naming starts working properly, so wanted to understand if url.full , url.path are stable to adopt or we are missing a trick in the book or stick to http.url for consistency?

Config JSON Snippet "processors": [ { "type": "attribute", "actions": [ { "key": "url.full", "pattern": "^(?<httpProtocol>.*):\\/\\/(?<httpDomain>[^\\/]+)\\/(?<httpPath>[^\\?]+)?(?<httpQueryParams>.*)", "action": "extract" } ] }, { "type": "span", "name": { "fromAttributes": [ "http.request.method", "httpPath" ], "separator": " " } }

To Reproduce

Using a commercial COTS system, I am unable to submit a reproducible use case.

System information

Please provide the following information:

• SDK Version: 3.7.2
• OS type and version: RHEL 8.10
• Application Server type and version (if applicable): COTs
• Using spring-boot? NA
• Additional relevant libraries (with version, if applicable): NA

Logs

I can capture logs if required.

Screenshots

[zoomingrocket]

@trask - Any feedback on this, is this Otel upstream behavior vs Azure? Is it safe to continue using http.url, or do we need to check if a bug is causing the url.full, not to be populated in all scenarios? Thanks!

[trask]

You should be able to use the stable HTTP semconv in 3.7.2. All of the upstream OTel HTTP instrumentation is emitting the stable HTTP semconv now.

The older HTTP semconv is also supported (for backwards compatibility).

[zoomingrocket]

@trask - Thanks, if we switch back to http.url it seems to work for all cases, so it seems like in some cases, upstream Otel semantics are not accurate, possibly.

[trask]

oh, I remembered, url.full is only populated on CLIENT (dependency) spans

for SERVER (request) spans, you'll want to use url.path

check out

• https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md#http-client-span
• https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md#http-server

[zoomingrocket]

@trask - Is there an easy way I can extract from either url.full or url.path while setting an attribute? We are setting the extracted attribute as the span name. Since it's a COTS system, I am not explicitly choose between server-side and client-side.

"processors": [ { "type": "attribute", "actions": [ { "key": "url.full", "pattern": "^(?<httpProtocol>.*):\\/\\/(?<httpDomain>[^\\/]+)\\/(?<httpPath>[^\\?]+)?(?<httpQueryParams>.*)", "action": "extract" } ] }, { "type": "span", "name": { "fromAttributes": [ "http.request.method", "httpPath" ], "separator": " " } }

[trask]

what if you set up two processors, one to handle url.full and one to handle url.path?

[zoomingrocket]

@trask - I thought of setting up two processors, but how do i do if/else based on which processor successfully has the value extracted in httpPath ? If i use the same attribute name it will simply overwrite based on the order i suppose? For short term i am sticking with http.url but would like to eventually align with recommended new http semantics to avoid issues down the line.

[trask]

If i use the same attribute name it will simply overwrite based on the order i suppose?

I think only one of them should match, so I don't think they would overwrite each other