feat(koa): Adds support to ignore a span by its layer name

[MrFabio]

Which problem is this PR solving?

• Adds ignoreLayersName option to instrumentation constructor config to allow layers to be ignored by its name.
• Currently we have the ignoreLayersType config, this new one will run after this check.
• It is useful if we want to ignore some layers like logger, allowedMethods, and some ones with no name. It also helps with reducing the number of spans.

Short description of the changes

• Defines KoaInstrumentationConfig with ignoreLayersName which is an array of string (layer names):
• Utils module with isLayerNameIgnored to check if a layer should be ignored by the name
• Modifies _patchLayer to check if the layer is ignored by the config

[laurit]

Did you consider using a SpanProcessor for this?

[adamleantech]

@laurit good suggestion, I wasn't aware of that

[adamleantech]

@laurit updated PR as per your suggestion. I've realised that there is probably an issue with my previous PR for logback MDC in that the "baggage." prefix should be on the key not the value

[laurit]

@adamleantech thanks for reporting, I'll fix it

[trask]

I wonder if otel.javaagent.span.add-baggage should take a list of baggage to add (or * for all), this would match otel.instrumentation.logback-appender.experimental.capture-mdc-attributes

and maybe we should do the same for otel.instrumentation.logback-mdc.add-baggage?

[evantorrie]

I'm interested in this same functionality but for use as an AutoConfigureSpi addition to a manually instrumented program (which uses the AutoConfigure SDK extension).

Is there anything which ties AgentTracerProviderConfigurer to the java agent (other than the name?).

Not for this PR obviously, but I wonder if this and AddThreadDetailsSpanProcessor could be relocated into the https://github.com/open-telemetry/opentelemetry-java repo as some sort of sdk-extension-customizer artifact?

[breedx-splk]

Is there anything which ties AgentTracerProviderConfigurer to the java agent (other than the name?).

Yeah, this configurer is coupled to the agent through the AgentConfig as well...but I think there's room for that to be a separate responsibility (separate PR).

Not for this PR obviously, but I wonder if this and AddThreadDetailsSpanProcessor could be relocated into the https://github.com/open-telemetry/opentelemetry-java repo as some sort of sdk-extension-customizer artifact?

I am liking this idea. @jack-berg and @jkwatson what do you think? Is there room for add-on processors like this in the core repo, or would you prefer to see it as a contrib addition, or something else?

[jack-berg]

Contrib is the appropriate place for this. If such a processor were to occur in the spec, we could promote that component the core repo.

[galbash]

Has this been contributed to the contrib repo / exists on the java agent?

[trask]

Has this been contributed to the contrib repo / exists on the java agent?

not yet