Implement a dedicated reactor-netty 1.0 instrumentation #4662
Conversation
mateuszrzeszutek
requested review from
anuraaga,
iNikem,
jkwatson,
laurit,
pavolloffay,
trask and
tylerbenson
as code owners
| if (propagatedContext.useClientContext) { | ||
| context = contextView.getOrDefault(ReactorContextKeys.CLIENT_CONTEXT_KEY, null); | ||
| } | ||
| if (context == null) { | ||
| context = contextView.getOrDefault(ReactorContextKeys.CLIENT_PARENT_CONTEXT_KEY, null); | ||
| } |
There was a problem hiding this comment.
is the fallback in case of useClientContext important? (vs straight if/else here)
There was a problem hiding this comment.
It is -- when reactor-netty span is suppressed and client context is not accessible from the reactor's ContextView we still want to execute the doOn*() callbacks with the parent context in scope.
.../io/opentelemetry/javaagent/instrumentation/reactornetty/v1_0/HttpClientInstrumentation.java
Outdated
Show resolved
Hide resolved
.../io/opentelemetry/javaagent/instrumentation/reactornetty/v1_0/HttpClientInstrumentation.java
Outdated
Show resolved
Hide resolved
...ntelemetry/javaagent/instrumentation/reactornetty/v1_0/HttpResponseReceiverInstrumenter.java
Outdated
Show resolved
Hide resolved
...ntelemetry/javaagent/instrumentation/reactornetty/v1_0/HttpResponseReceiverInstrumenter.java
Show resolved
Hide resolved
...ntelemetry/javaagent/instrumentation/reactornetty/v1_0/HttpResponseReceiverInstrumenter.java
Outdated
Show resolved
Hide resolved
| // connection is actually an instance of HttpClientOperations - a package private class that | ||
| // implements both Connection and HttpClientResponse |
...o/opentelemetry/javaagent/instrumentation/reactornetty/v1_0/ReactorNettyClientSslTest.groovy
Show resolved
Hide resolved
...ntelemetry/javaagent/instrumentation/reactornetty/v1_0/ReactorNettyConnectionSpanTest.groovy
Show resolved
Hide resolved
| // needs to be called after original method to prevent StackOverflowError | ||
| callDepth.decrementAndGet(); |
There was a problem hiding this comment.
can you move the callDepth update to beginning of these methods? I'm just paranoid about resetting thread local state 😄
There was a problem hiding this comment.
I have to decrement the count after the original response*() method is called, that's why they're the last thing I'm calling. I've wrapped those invocations in try-finally blocks - now the counter will always be decremented.
There was a problem hiding this comment.
oh, i completely missed the skipOn and what was happening here 👍
|
|
||
| Context context = instrumenter().start(parentContext, config); | ||
| contextHolder.context = context; | ||
| return ContextPropagationOperator.runWithContext(mono, context) |
There was a problem hiding this comment.
nice! it looks like pure context API is still useful even without extra convenience we discussed to start spans
There was a problem hiding this comment.
Yes, it turned out to be super useful this time 🚀
Co-authored-by: Trask Stalnaker <[email protected]>
…ry#4662) * Implement a dedicated reactor-netty 1.0 instrumentation * Apply suggestions from code review Co-authored-by: Trask Stalnaker <[email protected]> * code review comments * code review comments * code review comments Co-authored-by: Trask Stalnaker <[email protected]>
This PR introduces a completely new reactor-netty 1.0 instrumentation; one that does not rely on netty client instrumentation to produce telemetry. The HTTP client span is now the parent of RESOLVE/CONNECT/SSL spans, as I suggested in #4617:
(Now I only need to change the kind of those nested spans from
INTERNALtoCLIENT...)CC @lmolkova