Instrumentation layers and suppressing duplicates

[lmolkova]

Proposal to create clarity on instrumentation layers interaction and how to suppress duplicate layers (e.g. multiple instrumented HTTP clients layers).

cc @trask

[lmolkova]

@iNikem I hear your concern to have no suppression at all - I added an open question. I'd still like to understand why we'd need it and how common this need it.

[lmolkova]

Based on the discussions on the instrumentation SIG meeting, I've changed this OTEP to minimize tracing API changes. With the current approach, instrumentation specifies type at span creation time and SDK returns a suppressed span that's very similar to sampled-out, except it never becomes current.

Example: https://github.com/lmolkova/opentelemetry-java/pull/1/files#diff-48014f0437bde243933a6c8902a1f386fab6c78d6777019f24db1951e0070fc4

Open questions:

• messaging spans don't work great with it and I suggest working on it in messaging spec (there are more reasons than clear layering and suppression)
• adding optional optimization API to let instrumentation check first if span should be started
• defaults
• naming improvements are always welcome

[tedsuo]

@trask @lmolkova is this something the HTTP semconv working group would like to pick up again?

[trask]

@trask @lmolkova is this something the HTTP semconv working group would like to pick up again?

the scope of the current incarnation of the HTTP semconv working group is "just" stability. we discussed this and believe it can be addressed post-stability.