Skip to content

Conversation

@laurit
Copy link
Contributor

@laurit laurit commented Nov 4, 2025

Add an SPI for customizing http client url.template attribute and the http client span name that is computed from it. This PR also includes a regular expression based customizer that allows for matching the http client url agains regular expressions to produce url templates. It can be configured by setting otel.instrumentation.http.client.url-template-rules to a semicolon separated string consisting of replacement rules where each rule is a comma separated triplet of regex pattern used to match url, replacement, whether this rule can override existing url template (optional parameter). Url template is computed via pattern.matcher(url).replaceFirst(replacement) so replacement can contain capture groups used in the pattern. Note that since url templates are experimental otel.instrumentation.http.client.emit-experimental-telemetry also needs to be set.

@laurit laurit requested a review from a team as a code owner November 4, 2025 14:06
@laurit laurit added this to the v2.22.0 milestone Nov 5, 2025
@zeitlinger
Copy link
Member

This PR does not implement declarative config.

Declarative config is ready to be used, so we should support declarative config only - similar to how you have to use declarative config for more advanced method config

Copy link
Member

@zeitlinger zeitlinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering how this customizer is/should be related to the recently added InstrumenterCustomizer. They are closely related, so maybe InstrumenterCustomizer can just be extended.

@laurit
Copy link
Contributor Author

laurit commented Nov 5, 2025

I'm wondering how this customizer is/should be related to the recently added InstrumenterCustomizer. They are closely related, so maybe InstrumenterCustomizer can just be extended.

I don't know how to implement this on top of InstrumenterCustomizer as it is.

@laurit
Copy link
Contributor Author

laurit commented Nov 5, 2025

This PR does not implement declarative config.

Declarative config is ready to be used, so we should support declarative config only - similar to how you have to use declarative config for more advanced method config

implemented

@zeitlinger
Copy link
Member

zeitlinger commented Nov 5, 2025

I'm wondering how this customizer is/should be related to the recently added InstrumenterCustomizer. They are closely related, so maybe InstrumenterCustomizer can just be extended.

I don't know how to implement this on top of InstrumenterCustomizer as it is.

something like customizer.addAttributesExtractor(HttpExperimentalAttributesExtractor.createWithHttpClientUrlTemplateCustomizer(..))

but that's not thought through

@zeitlinger
Copy link
Member

I wonder what the right place to document this is, in particular the declarative config syntax. Maybe a javadoc or README?

@laurit
Copy link
Contributor Author

laurit commented Nov 5, 2025

something like customizer.addAttributesExtractor(HttpExperimentalAttributesExtractor.createWithHttpClientUrlTemplateCustomizer(..))

but that's not thought through

The first hurdle is that you need to somehow tell which instrumenters are for http clients, incidentally I was planning to implement something for it. Assuming you can do it then you'd need some way to detect whether this attribute is already set. This can be done by calling build on the AttributesBuilder or relying on the internal workings of UnsafeAttributes. After that you'd need to somehow also influence the span naming which is tricky because here you also need to tell whether the original name already had the template appended which. I think the current solution is simpler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants