Repository navigation
Span Naming - New HTTP Semantic Behavior http.url v/s url.full #4226
Description
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
Activity
zoomingrocket commentedon Jun 17, 2025
Trask Stalnaker (@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 commentedon Jun 17, 2025
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 commentedon Jun 23, 2025
Trask Stalnaker (@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 commentedon Jun 23, 2025
oh, I remembered,
url.fullis only populated on CLIENT (dependency) spansfor SERVER (request) spans, you'll want to use
url.pathcheck out
zoomingrocket commentedon Jun 24, 2025
Trask Stalnaker (@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 commentedon Jul 13, 2025
what if you set up two processors, one to handle
url.fulland one to handleurl.path?zoomingrocket commentedon Jul 28, 2025
Trask Stalnaker (@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 commentedon Jul 28, 2025
I think only one of them should match, so I don't think they would overwrite each other