Change enable property on Instrumenter to a Predicate<Instrumenter> or a Supplier<Boolean>

[osvaldopina]

Is your feature request related to a problem? Please describe.

Allows a fine grain control over span creation for a Instrumenter.

Describe the solution you'd like

...
private final Predicate<Instrumenter> enabled;
...

...

 public boolean shouldStart(Context parentContext, REQUEST request) {
     if (!enabled.test(this)) {
      return false;
    }

...

Or

...
private final Supplier<Boolean> enabled;
...

...

 public boolean shouldStart(Context parentContext, REQUEST request) {
     if (!enabled.get()) {
      return false;
    }

...

Describe alternatives you've considered

I could not find any other way to enable or disable Instrumenter span creation on th fly. If there is such a mecanism this feature request would not be necessary.

Additional context

No response

[laurit]

Please describe why you would need this.

[osvaldopina]

In my use case I create the instrumenters, both the ones provided by otel instrumentation and the ones that we develped internally, and I would like to be able to enable or disable a specific Instrumenter at runtime.

[trask]

hi @osvaldopina, is this to support dynamic configuration? e.g. #12251 (comment)

[osvaldopina]

Hi @trask. Yes, that's the goal.

[trask]

there's a broader effort happening that I think may address your use case, check out open-telemetry/opentelemetry-java#6687 and #12251 (comment)

[osvaldopina]

I took a look at the issues you pointed out. The 6687 has a broader effect of enabling or disabling all traces. I need something tied to each instrumenter allowing a much finer control. I saw 12251 and, as it is now, it is a list of intentions and my proposition could address one aspect of it. Looking at 6687 I realize that I can achieve what I need if the final clause is removed from the enabled attribute.

[trask]

The 6687 has a broader effect of enabling or disabling all traces

it is per tracer (i.e. per instrumentation)

[trask]

you can see more thoughts about 6687 in the spec work behind it: open-telemetry/opentelemetry-specification#3867