Instrument spring integration. #15
Conversation
| protected void populatePropagatedContext(Span span, Message<?> message, | ||
| MessageChannel channel) { | ||
| if (span != null) { | ||
| Span currentContext = getCurrentSpan(); |
There was a problem hiding this comment.
I'm still fuzzy on what I should be doing with the span here. This is leftover from SecurityContextPropagationChannelInterceptor.
|
@spencergibb , @dsyer , your PR is on our radar. Thanks for your patient! |
Via a global channel interceptor that adds headers to messages. fixes gh-14
The client recv/send events have no meaning in a messaging context, so we don't need to send them. Also added a new protected method as the inverse of populatePropergatedContext. Rebased on master and fixed conflicts. See gh-15
dsyer
force-pushed
the
spring-integration
branch
from
c49fb43 to
cfd6fe6
Compare
|
@spencergibb I rebased onto master with that last commit. I see what you are doing now, and it's quite narrowly restricted to thread context propagation. We need more components so we can actually manage the context (create spans, mark them as ended etc.) when messages enter and leave the system. That is probably going to be harder, so maybe we need to ask @artembilan and Gary for help. Or maybe it needs to be aware of spring-cloud-stream (cc @markfisher). |
There was an ordering error in the conditions as well, causing the wrong async customizers to be registered. Another issue was the servlet async processing (request atribute not cached in all branches) resulting in multiple spans per request.
So that it can be used to keep the MDC populated when an async request is continued. Fixes gh-18
This might not be the ultimate solution but it should give us something to look at and collect some data. It doesn't solve the sampling problem, or the headers copying problem. See gh-14
Via a global channel interceptor that adds headers to messages.
fixes gh-14
For review @dsyer @garyrussell @artembilan