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

Non-blocking UUID generation for Spans #3325

Open
Andrevmatias opened this issue Apr 4, 2024 · 1 comment
Open

Non-blocking UUID generation for Spans #3325

Andrevmatias opened this issue Apr 4, 2024 · 1 comment

Comments

@Andrevmatias
Copy link

Andrevmatias commented Apr 4, 2024

Problem Statement

The UUID generation for Spans is made using UUID.randomUUID() deep within the library and can't be replaced easily.

UUID.randomUUID() can be a blocking method depending on the Java distribution and OS configurations and it's resulting in a lot of our threads being blocked, impairing the system performance. We don't have control over the servers were our system is installed.

Also, the Spans and Transactions are created for every request regardless of whether it will be sent to Sentry. It occurs before the sampling process and is created even if sentry.traces-sample-rate is 0 or null. This creates a lot of UUIDs that I think are not even necessary.

Solution Brainstorm

  • Allow to set a non-blocking UUID generation fo Spans on Sentry initialization options
  • Expose the UUID generation method as a spring component/service so it can be overwritten
  • Create UUIDs just for the events that are effectively sent to Sentry
  • Allow to disable instrumentation completely through configuration without disabling sending other types of events.
@adinauer
Copy link
Member

adinauer commented Apr 8, 2024

Hello @Andrevmatias thanks for opening this issue. We'll add this to the backlog but can't say when we'll get to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Status: Needs Discussion
Development

No branches or pull requests

2 participants