Make GlobalIgnoresMatcher configurable

[pavolloffay]

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

I want to instrument java.io.InputStream and java.io.OutputStream e.g. https://github.com/hypertrace/javaagent/blob/c320487308481c4ca7a90ec0f5b054ea1788e7c2/instrumentation/java-streams/src/main/java/io/opentelemetry/javaagent/instrumentation/hypertrace/java/inputstream/InputStreamInstrumentationModule.java#L71

The core configuration ignores almost all types from java. package, hence my instrumentation does not work on e.g. ByteArrayInputStream etc.

opentelemetry-java-instrumentation/javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/matcher/GlobalIgnoresMatcher.java

Line 105 in 4e52b3e

if (name.startsWith("java.")) {

Describe the solution you'd like

Make the GlobalIgnoresMatcher configurable.

[pavolloffay]

any proposals how to make the global ignore matchers configurable?

[anuraaga]

Do you think a simple csv property of excluded prefixes could cut it? So we wouldn't be able to filter on the exclude, but it is the simplest form of configurability I think. Wondering if it's enough for the use case.

[pavolloffay]

Do you think a simple csv property of excluded prefixes could cut it?

There are two use cases: 1. adding more exclusion patterns and 2. including some classes that the upstream excludes (my use-case). Given how the exclusion is written it will be better to provide a customized implementation.

A programmatic SPI will be probably more flexible and optimized. Here is some proposal:

interface GlobalIgnoresMatcherProvider {
  <T extends TypeDescription> ElementMatcher.Junction<T> type();
 ElementMatcher.Junction.AbstractBase<ClassLoader> classloader();

// or order
int priority();
}

The matcher with the highest priority/order will be installed.