Instrument ContextPropagationOperator to bridge lib/agent calls #4786
Conversation
lmolkova
requested review from
anuraaga,
iNikem,
jkwatson,
laurit,
mateuszrzeszutek,
pavolloffay,
trask and
tylerbenson
as code owners
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. |
...entelemetry/javaagent/instrumentation/reactor/ContextPropagationOperatorInstrumentation.java
Outdated
Show resolved
Hide resolved
I like this PR (and muzzle changes in #4797); perhaps we'll need to implement a similar bridge for the |
lmolkova
force-pushed
the
reactor-context-agent-bridge
branch
from
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
Fixes reactor part of #4666