Link JMS receive span with the producer span #6804
Merged
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
laurit
approved these changes
Oct 5, 2022
Good find 👍 |
laurit
pushed a commit
that referenced
this pull request
Oct 6, 2022
Similar to #6804, but for RabbitMQ. Also changed the span kind of the receive span to `CONSUMER`, to match the spec.
LironKS
pushed a commit
to helios/opentelemetry-java-instrumentation
that referenced
this pull request
Oct 23, 2022
Resolves open-telemetry#6779 In JMS you can have either the consumer receive span or the consumer process span (unlike Kafka, where the process span is always there and the receive span is just an addition) - in scenarios where polling (receive) is used, I think it makes sense to add links to the producer span to preserve the producer-consumer connection. Current messaging semantic conventions don't really describe a situation like this one, but the open-telemetry/oteps#220 OTEP mentions that links might be used in a scenario like this one - which makes me think that adding links here might be a not that bad idea.
LironKS
pushed a commit
to helios/opentelemetry-java-instrumentation
that referenced
this pull request
Oct 23, 2022
Similar to open-telemetry#6804, but for RabbitMQ. Also changed the span kind of the receive span to `CONSUMER`, to match the spec.
LironKS
pushed a commit
to helios/opentelemetry-java-instrumentation
that referenced
this pull request
Oct 31, 2022
Resolves open-telemetry#6779 In JMS you can have either the consumer receive span or the consumer process span (unlike Kafka, where the process span is always there and the receive span is just an addition) - in scenarios where polling (receive) is used, I think it makes sense to add links to the producer span to preserve the producer-consumer connection. Current messaging semantic conventions don't really describe a situation like this one, but the open-telemetry/oteps#220 OTEP mentions that links might be used in a scenario like this one - which makes me think that adding links here might be a not that bad idea.
LironKS
pushed a commit
to helios/opentelemetry-java-instrumentation
that referenced
this pull request
Oct 31, 2022
Similar to open-telemetry#6804, but for RabbitMQ. Also changed the span kind of the receive span to `CONSUMER`, to match the spec.
LironKS
pushed a commit
to helios/opentelemetry-java-instrumentation
that referenced
this pull request
Dec 4, 2022
Resolves open-telemetry#6779 In JMS you can have either the consumer receive span or the consumer process span (unlike Kafka, where the process span is always there and the receive span is just an addition) - in scenarios where polling (receive) is used, I think it makes sense to add links to the producer span to preserve the producer-consumer connection. Current messaging semantic conventions don't really describe a situation like this one, but the open-telemetry/oteps#220 OTEP mentions that links might be used in a scenario like this one - which makes me think that adding links here might be a not that bad idea.
LironKS
pushed a commit
to helios/opentelemetry-java-instrumentation
that referenced
this pull request
Dec 4, 2022
Similar to open-telemetry#6804, but for RabbitMQ. Also changed the span kind of the receive span to `CONSUMER`, to match the spec.
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.
Resolves #6779
In JMS you can have either the consumer receive span or the consumer process span (unlike Kafka, where the process span is always there and the receive span is just an addition) - in scenarios where polling (receive) is used, I think it makes sense to add links to the producer span to preserve the producer-consumer connection. Current messaging semantic conventions don't really describe a situation like this one, but the open-telemetry/oteps#220 OTEP mentions that links might be used in a scenario like this one - which makes me think that adding links here might be a not that bad idea.