getsentry / sentry-ruby

Sentry SDK for Ruby
https://sentry.io/for/ruby
MIT License
930 stars 495 forks source link

Span truncation #1845

Open sl0thentr0py opened 2 years ago

sl0thentr0py commented 2 years ago

Add some span truncation logic similar to frames/breadcrumbs

Linuus commented 2 years ago

Would this solve the issue we have where our most important events are being dropped? (I've been asking about this in the Discord channel since this summer).

For instance, let's say we have a background job which is doing some work (enqueueing other jobs, making HTTP calls etc). Sometimes they take a long time and can't see those performance traces because they are being dropped (I think). Now, the performance traces in Sentry all look fast and fine, but the really interesting ones that I want to debug aren't in there at all, which makes it a bit pointless :(

So, I'd be a very happy customer whenever this is implemented 🙏

smeubank commented 2 years ago

@sl0thentr0py by truncation is it temporal cut or content of span.

@Linuus would be interested to know if you can tell us the reason why & when your spans are being dropped?

bmulholland commented 2 years ago

I’ve experienced dropped spans transactions with long-running http requests before. The request took more than a few seconds, and I guess was then too big to come through. I verified this with support, who pointed me to this issue. #70304

Linuus commented 2 years ago

@Linuus would be interested to know if you can tell us the reason why & when your spans are being dropped?

it’s not spans that are dropped. It’s the entire event. I can’t see performance traces for these at all.

For instance, we have a background job which is enqueueing a couple of thousand other jobs. Each of those enqueues gets a span (activejob.enqueue_at or something). With all those spans the payload gets too big and it’s all dropped.

booleanbetrayal commented 1 year ago

We are also curious about this. We are logging oversized transactions in which spans contains large blocks of SQL that should possibly be truncated in some fashion. As it stands, our most SQL-verbose transactions appear to be getting dropped due to payload sizing constraints.