Exclude URLs from Tracing

[jakob-o]

Is your feature request related to a problem? Please describe.
As already mentioned here open-telemetry/opentelemetry-specification#173 I'd like to be able to exclude or sample a list of URLs / URL-Patterns from instrumentation. In my case particularly to avoid generating many events from health- and liveness-checks.

Describe the solution you'd like
I opened the issue open-telemetry/opentelemetry-java#1552 to discuss if / how tracing might be disabled from instrumentation.
To my knowledge there currently is no API / SDK method to disable tracing centrally on the context.
If I understood correctly a (maybe temporary) solution might be to create a non-recording / invalid span in the HTTP instrumentation, which due to the ParentOrElse-Sampler, would lead to ignoring child spans as well, if the request matches a URL pattern.
Any hint to where this would be architecturally appropriately implemented is highly appreciated.
Maybe in the HttpServerTracer?

Describe alternatives you've considered
We already attempted to use the otel.trace.classes.exclude but only succeeded in completely disabling WebMvc instrumentation.

/CC @gabrielthunig @spaletta

[iNikem]

If I understood correctly a (maybe temporary) solution might be to create a non-recording / invalid span in the HTTP instrumentation, which due to the ParentOrElse-Sampler, would lead to ignoring child spans as well, if the request matches a URL pattern.
Any hint to where this would be architecturally appropriately implemented is highly appreciated.
Maybe in the HttpServerTracer

That seems like a reasonable approach :)

[anuraaga]

Been trying auto instrumentation in a container lately, and was slightly annoyed myself with tracing of health check. Then a customer trying it out independently had the same feedback - it's exactly the kind of input we're hoping for in trials :) So I may actually mark this required for GA, the UX is impacted a lot with having no control of tracing by URL pattern.

[pavolloffay]

I have started looking into this.

Is there a proposed design for this? In OpenTracing this was an instrumentation feature. The instrumentation check if the URL matches exclude pattern if yes then the span wasn't created. However if the excluded URL uses another instrumentation (or makes downstream call) that would create a span. The question is whether we want to exclude just specific URLs or the whole trace starting at that URL.

[iNikem]

Yes, we have a proposal right in the task's description:

If I understood correctly a (maybe temporary) solution might be to create a non-recording / invalid span in the HTTP instrumentation, which due to the ParentOrElse-Sampler, would lead to ignoring child spans as well, if the request matches a URL pattern.
Any hint to where this would be architecturally appropriately implemented is highly appreciated.
Maybe in the HttpServerTracer?

This should lead to ignoring the whole subtree starting from that SERVER span.

[pavolloffay]

+1 I think that is the right way to go open-telemetry/opentelemetry-specification#173 (comment). It would also make sense to have a consolidated config property for this.

@iNikem what is the API to create non-recording span? In OT there was sampling.priority=bool tag that could be applied on the span builder https://github.com/opentracing/specification/blob/master/semantic_conventions.yaml#L26

[iNikem]

I think the right way is to use one of the factory methods on io.opentelemetry.trace.DefaultSpan.

[pavolloffay]

Yeah, I wanted to avoid having two paths of span creation.

[anuraaga]

Sorry if double-spam, I thought I had already posted this. How about we have a special Sampler itself configured that delegates to the default, except for when the path matches the allow list, then it's ParentOnly? It means we need to refactor to make sure our tracers set attributes on Span.Builder instead of Span - a little annoying but we should have been doing that already so maybe good motivation for it.

[anuraaga]

Note that DefaultSpan might get renamed to something that would be naming-wise not a good fit with what we want to do here open-telemetry/opentelemetry-specification#994 (review)