Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add process spans to aws-1 sqs instrumentation #9796

Merged
merged 3 commits into from
Nov 7, 2023

Conversation

laurit
Copy link
Contributor

@laurit laurit commented Nov 2, 2023

Aws-1 changes from #9778
This pr makes SQS instrumentation create similarly telemetry to kafka instrumentation, also support is added for the receive telemetry flag. Like in kafka instrumentation process span is created by placing messages in a custom list whose iterator creates span on next and closes it on hasNext.

@laurit laurit requested a review from a team as a code owner November 2, 2023 11:51
@trask
Copy link
Member

trask commented Nov 6, 2023

Like in kafka instrumentation process span is created by placing messages in a custom list whose iterator creates span on next and closes it on hasNext.

what do you think of making this opt-in with a warning? #1947 (comment)

@laurit
Copy link
Contributor Author

laurit commented Nov 7, 2023

what do you think of making this opt-in with a warning? #1947 (comment)

Making it opt-in is fine, but it raises the question what should the behavior be when this feature is disabled? Currently with default (receiver telemetry disabled) in this pr the only consumer side span is created is the process span from the iterator. If we allow disabling this process span should we create some other span, what should that be? Currently we create a receive span for each individual message, which probably doesn't conform to messaging semantic conventions.
The ability to link up producer span with spans created during message processing is a common request from our customers. While I totally agree that this instrumentation is flaky by design I don't remember any recent issues with kafka, so perhaps it is good enough to work in practice? Should we handle this in complaint driven way?

@trask
Copy link
Member

trask commented Nov 7, 2023

I don't remember any recent issues with kafka

good point, maybe #5826 made things "good enough"

The ability to link up producer span with spans created during message processing is a common request from our customers.

ya, this is pretty important, you've convinced me, thx

@trask trask merged commit 23a6a3e into open-telemetry:main Nov 7, 2023
47 checks passed
@laurit laurit deleted the aws1-sqs-spans branch November 7, 2023 16:48
Abhishekkr3003 pushed a commit to Abhishekkr3003/opentelemetry-java-instrumentation that referenced this pull request Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants