Producer SpanKind does not always imply a remote call #371
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
It's popular in asynchronous scenarios to send messages in batches. In this case, each message may (and should) carry a unique context to be individually traceable. Arguably it means creating span per message. Sending a batch (which is remote outgoing call) is represented by a different span that is linked to all of the messages span contexts. So async messaging scenarios with batching involve * *message* spans and they map to PRODUCER kind (they are parent of asynchronous request) * *send* span that is CLIENT kind (which is remote outgoing call). But it is not a parent of any asynchronous request In some cases (not involving batching) it is possible that dedicated *message* span is not needed and *send* may represent both: context in the message and remote outgoing call. In this case, such span should have PRODUCER kind
lmolkova
requested review from
AloisReitbauer,
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
jmacd,
reyang,
SergeyKanzhelev,
songy23,
tedsuo,
tigrannajaryan and
yurishkuro
as code owners
|
Could you update the spec language to explain why PRODUCER may or may not be remote? Also I suspect that if PRODUCER has this property, so does CONSUMER. Should they both be marked maybes? |
…rios also could be local
|
@jmacd sure, done. I wish we had a spec for async messaging documented, but it should not block v1. I will try to come up with one |
|
Not sure "may be" is clear enough, but otherwise it looks good to me. |
carlosalberto
approved these changes
Dec 6, 2019
jmacd
reviewed
Dec 6, 2019
added 2 commits
December 6, 2019 21:09
jmacd
approved these changes
Dec 7, 2019
SergeyKanzhelev
approved these changes
Dec 10, 2019
bogdandrutu
approved these changes
Dec 10, 2019
Oberon00
reviewed
Dec 10, 2019
SergeyKanzhelev
approved these changes
Dec 10, 2019
|
Active for more than 3 days and have enough sign offs. Merging |
SergeyKanzhelev
pushed a commit
to SergeyKanzhelev/opentelemetry-specification
that referenced
this pull request
Feb 18, 2020
…#371) * Producer SpanKind is not always a remote call It's popular in asynchronous scenarios to send messages in batches. In this case, each message may (and should) carry a unique context to be individually traceable. Arguably it means creating span per message. Sending a batch (which is remote outgoing call) is represented by a different span that is linked to all of the messages span contexts. So async messaging scenarios with batching involve * *message* spans and they map to PRODUCER kind (they are parent of asynchronous request) * *send* span that is CLIENT kind (which is remote outgoing call). But it is not a parent of any asynchronous request In some cases (not involving batching) it is possible that dedicated *message* span is not needed and *send* may represent both: context in the message and remote outgoing call. In this case, such span should have PRODUCER kind * Explain why producer spans are not necessarily remote and async scenarios also could be local * review comments * lint
2 tasks
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
…#371) * Producer SpanKind is not always a remote call It's popular in asynchronous scenarios to send messages in batches. In this case, each message may (and should) carry a unique context to be individually traceable. Arguably it means creating span per message. Sending a batch (which is remote outgoing call) is represented by a different span that is linked to all of the messages span contexts. So async messaging scenarios with batching involve * *message* spans and they map to PRODUCER kind (they are parent of asynchronous request) * *send* span that is CLIENT kind (which is remote outgoing call). But it is not a parent of any asynchronous request In some cases (not involving batching) it is possible that dedicated *message* span is not needed and *send* may represent both: context in the message and remote outgoing call. In this case, such span should have PRODUCER kind * Explain why producer spans are not necessarily remote and async scenarios also could be local * review comments * lint
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.
It's popular in asynchronous scenarios to send messages in batches.
In this case, each message should carry a unique context to be individually traceable. Arguably it means creating span per message. Such spans do not represent remote calls.
Sending a batch (which is remote outgoing call) is represented by a different span that is linked to all of the messages span contexts.
So async messaging scenarios with batching involve
In some cases (not involving batching) it is possible that dedicated message span is not needed and send may represent both: context in the message and remote outgoing call. In this case, such span should have PRODUCER kind