Does java instrumentation agent follow latest semantic-conventions?

[missTam]

With the semantic-conventions release v1.26.0 url.template information was added on the HTTP client metric (PR).

Does java instrumentation agent (latest) support this semantic-convention?

How does one generally check compatibility between java-instrumentation and semantic-convention versions?

Thanks!

[laurit]

No, java agent does not support url.template. Note that vast majority of java http clients have no concept of url templates so they'll not fill this attribute. This attribute could for example be used with spring WebClient if it is used in a certain way, see #10506 for an attempt to implement this that predates url.template.

How does one generally check compatibility between java-instrumentation and semantic-convention versions?

I don't think there is an easy way. You'll have to examine the source code for definitive answers.

[missTam]

Thanks for your response!

If I follow correctly, for this attribute to become available, Spring WebClient would need to provide something like a uriTemplate, so you could use it in your implementation, as proposed in #10506 ?

I thought the uri-templating logic could be owned by you..?

[laurit]

For http clients that don't provide a template an extension point could be implemented where users could provide custom logic to deduce the template from an url. It may also be possible to implement this in a way that could use rules from a configuration file. Something like if url matches some regex then return some template.

[missTam]

I agree that relying on http clients to provide a template might be unrealistic to expect..

Do you envision this extension as part of the opentelemetry-java-instrumentation?

Another idea: would it make sense to say: 'We will export url.template for you if you provide it and it matches some regex, otherwise, we will ignore it. How you get it (Spring WebClient offers it or you extended the WebClient with your own custom attribute), we don't care' ?

[laurit]

I agree that relying on http clients to provide a template might be unrealistic to expect..

most http clients are not designed for this so they'll never provide it

Do you envision this extension as part of the opentelemetry-java-instrumentation?

yes, but it is just an idea. It is possible that it will never get implemented.

Another idea: would it make sense to say: 'We will export url.template for you if you provide it and it matches some regex, otherwise, we will ignore it. How you get it (Spring WebClient offers it or you extended the WebClient with your own custom attribute), we don't care' ?

I don't follow.

[trask]

one idea that has been discussed is that if/when something like open-telemetry/oteps#207 happens, then users could set their own url.template before calling the HttpClient and the instrumentation would automatically pick that up and stamp it on to the telemetry