Add span links to messaging system tracing#2610
Conversation
|
run integration tests |
|
run integration tests |
|
/test |
SylvainJuge
left a comment
There was a problem hiding this comment.
LGTM, mostly minor comments & questions.
| errorPool.recycle(error); | ||
| } | ||
|
|
||
| public void recycle(TraceContext traceContext) { |
There was a problem hiding this comment.
[minor] maybe rename this method to recycleSpanLink to avoid any confusion with recycling another TraceContext.
| public void recycle(TraceContext traceContext) { | |
| public void recycleSpanLink(TraceContext traceContext) { |
There was a problem hiding this comment.
Actually, it doesn't need to be specific for span links, it's for any potential use of pooled TraceContext, so I'll leave it just as is, similarly to all other recycle methods that differ by their argument type.
| */ | ||
| public <H, C> boolean addSpanLink(TraceContext.ChildContextCreatorTwoArg<C, HeaderGetter<H, C>> childContextCreator, | ||
| HeaderGetter<H, C> headerGetter, @Nullable C carrier) { | ||
| if (spanLinks.size() == MAX_ALLOWED_SPAN_LINKS) { |
There was a problem hiding this comment.
[minor] we might reach the limit and still be fine if the span link is already in the spanLinks collection, we should probably issue this warning only when we are unable to add to the collection, which also means the limit has to be added to UniqueSpanLinkArrayList.
There was a problem hiding this comment.
I started moving it, but losing the ability to log which span has the problem seems like a big compromise only for this extreme corner case where there are EXACTLY 1000 span links and repetitions in addition to that. Even if we encounter this somehow, this single logging is not so bad anyway.
apm-agent-core/src/main/java/co/elastic/apm/agent/impl/transaction/AbstractSpan.java
Show resolved
Hide resolved
apm-agent-core/src/main/java/co/elastic/apm/agent/configuration/MessagingConfiguration.java
Show resolved
Hide resolved
...kafka-base-plugin/src/main/java/co/elastic/apm/agent/kafka/KafkaConsumerInstrumentation.java
Outdated
Show resolved
Hide resolved
...headers-plugin/src/main/java/co/elastic/apm/agent/kafka/NewKafkaPollExitInstrumentation.java
Outdated
Show resolved
Hide resolved
...apm-kafka-headers-plugin/src/test/java/co/elastic/apm/agent/kafka/KafkaClientVersionsIT.java
Show resolved
Hide resolved
| assertThat(spans.size()).isGreaterThanOrEqualTo(1); | ||
| verifyPollSpanContents(spans); |
There was a problem hiding this comment.
[question] I'm not sure to understand here why we now have 1+ instead of exactly one previously.
There was a problem hiding this comment.
You can't without looking at the other changes - see https://github.com/elastic/apm-agent-java/pull/2610/files#diff-12e2c27883cbfcbc62d039b9bf284b58b2a743637f207e7309a5f9ce101ba544R372-R388 - for the new test I had to change the polling method so that it polls until all records are consumed, so it is non-deterministic how many polls actually occur. The other alternative to make it robust is wait for quite long before polling, which I didn't want.
Since I verify that these spans have the expected contents, and they all combined contain the expected span links, I think this is fine and properly reflects real scenarios.
| List<Message> processedBatch = messageBatch; | ||
| Transaction batchTransaction = null; | ||
|
|
||
| if (tracer.isRunning() && messageBatch != null && !messageBatch.isEmpty()) { |
There was a problem hiding this comment.
[minor] maybe return early in case where tracer is not running or batch is empty to prevent some if nesting
| active); | ||
| } | ||
|
|
||
| active = tracer.getActive(); |
There was a problem hiding this comment.
Isn't the active variable already set with the active span/transaction on line 80 ?
There was a problem hiding this comment.
Yes, but line 88 potentially activates a transaction. This basically says: "if there was an active span before, or if we just created one and activated it, I want to add span links in both cases".
There was a problem hiding this comment.
Because the flow of this method is a bit complicated and because the return value is complex one that may be affected by multiple decision branches, I prefer one return in such methods (related to the comment above), but it's definitely a mater of taste
…ain/java/co/elastic/apm/agent/kafka/KafkaConsumerInstrumentation.java Co-authored-by: SylvainJuge <syl20j@gmail.com>
…c/main/java/co/elastic/apm/agent/kafka/NewKafkaPollExitInstrumentation.java Co-authored-by: SylvainJuge <syl20j@gmail.com>
|
Below are screenshots reflecting the following scenario: a transaction sends two records to a Kafka "Request-Topic", waits for two corresponding reply records on a "Reply-Topic" and then iterates over the replies. Asynchronously, a "Batch-processing transaction" polls records from the "Request-Topic" and processes the record batch by sending a reply record for each request record. The test transaction: On the batch processing side: |







What does this PR do?
Closes #2489: