Weryj 2 days ago

I do have one major complaint though, in dotnet, the tracing/errors are always captured regardless of the sampling rate. So you end up with a lot more memory usage on high throughput/low memory services with no way to lower it.

There's a ticket now open to stop this, but it's still in progress.

3
brungarc 19 hours ago

Avoiding allocations when a transaction isn’t sampled should be pretty trivial. Only gotcha is that you’d still trace id propagation to tie errors together regardless of transactions. But tracing and transactions got decoupled a while ago so shouldn’t be a big problem. I’ll leave a comment on ticket pointing to this post

parthdesai 2 days ago

It's open source, you guys could always create a PR to fix it. That's the power of open source!

no_wizard 2 days ago

there's no guarantee it will get merged though, even if a PR is created.

Forking has down sides that can't be hand waved away too, especially for a service like this.

5Qn8mNbc2FNCiVV 1 day ago

It's just a client library, what's the alternative, put a proxy in front that drops 90% of the events

zeeg 2 days ago

Any chance you can link me to the ticket?

Feel free to email - david at sentry

Weryj 2 days ago

It looks like there was some motion a week ago.

https://github.com/getsentry/sentry-dotnet/issues/3636#event...