Open sobrinho opened 5 months ago
yep i can add, but also you can probably try out our Performance product and you'll get much more visibility into such things :) https://docs.sentry.io/platforms/ruby/performance/ https://docs.sentry.io/platforms/ruby/performance/instrumentation/automatic-instrumentation/
Indeed but the point here is to track times from a very specific exception.
So, if a Rack::Timeout exception happens for instance, I can see the exception and go straight to the query that took too long to execute.
we connect errors and traces together, so you can neatly go from a particular exception to the span waterfall for that entire request and can see the query immediately.
Every error is traced on the performance? What happens with the sampling in that case?
Describe the idea
We have breadcrumbs with the query like:
Would be helpful to have the timing of that query together with the breadcrumb:
Why do you think it's beneficial to most of the users
That will help with exceptions that might be caused due to slow endpoints such as graphql timeout middleware, rack-timeout and etc.
Possible implementation
https://github.com/getsentry/sentry-ruby/blob/master/sentry-rails/lib/sentry/rails/breadcrumb/active_support_logger.rb#L14-L18
Could be something like: