Instrument ContextPropagationOperator to bridge lib/agent calls - #4786
Conversation
trask
left a comment
trask
left a comment
There was a problem hiding this comment.
thx @lmolkova!
@mateuszrzeszutek @anuraaga would be great to get your thoughts on this. It's similar to the bridging we do on the OpenTelemetry API, but applied to a library instrumentation, which feels a little odd since typically I think of users using either library instrumentation -or- javaagent instrumentation, but not needing to use both. Maybe we could split out part of the reactor instrumentation module into an opentelemetry-extension-reactor module (similar to opentelemetry-extension-kotlin)?
| public class ContextPropagationOperatorInstrumentation implements TypeInstrumentation { | ||
| @Override | ||
| public ElementMatcher<TypeDescription> typeMatcher() { | ||
| return named("application.io.opentelemetry.instrumentation.reactor.ContextPropagationOperator"); |
Library itself can provide native/library instrumentation and then app developer brings in the agent. So this scenario is totally possible. |
I like this PR (and muzzle changes in #4797); perhaps we'll need to implement a similar bridge for the |
c661bde to
b19b66f
Compare
…-telemetry#4786) * Instrument ContextPropagationOperator to bridge lib/agent calls * more tests * clean up * up * lint * more lint * make runWithContext(Flux, ..) public * lint
4 participants
Fixes reactor part of #4666