Experimental option to suppress messaging receive spans #4187
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
trask
requested review from
anuraaga,
iNikem,
jkwatson,
laurit,
mateuszrzeszutek,
pavolloffay and
tylerbenson
as code owners
mateuszrzeszutek
approved these changes
Sep 22, 2021
...t/src/main/java/io/opentelemetry/javaagent/instrumentation/kafkaclients/KafkaSingletons.java
Show resolved
Hide resolved
...t/src/main/java/io/opentelemetry/javaagent/instrumentation/kafkaclients/KafkaSingletons.java
Outdated
Show resolved
Hide resolved
| static Consumer<Integer, String> consumer | ||
|
|
||
|
|
||
| def setupSpec() { |
There was a problem hiding this comment.
How about extracting a base class that'll contain the whole kafka setup?
...ents/kafka-clients-0.11/javaagent/src/test/groovy/KafkaClientSuppressReceiveSpansTest.groovy
Outdated
Show resolved
Hide resolved
…-to-suppress-messaging-receive-spans
trask
deleted the
experimental-option-to-suppress-messaging-receive-spans
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introducing this option was discussed in last week's Messaging SIG. Experience from Node is that users think messaging instrumentation is broken when the producer and consumer spans don't have the same traceId.
EDIT: the current modeling is correct per the current messaging semantic conventions, and you should be seeing links from consumers to producers, but links are not modeled great in all backends yet, which is where this option comes in handy (as well as if you just want a simpler trace structure)