You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are trialling the Cron Monitoring beta (which looks like a very promising product!), and have noticed a strangely erratic nature of our cron check ins: Sentry often reported them as timed out or missing when according to our data the scheduled workers ran on time and in reasonable time.
We also have set the sample_rate config option to 0.25 to report fewer exceptions to Sentry.
It appears that TransactionEvent is the only type of Event that is not affected by sample_rate, and is using its own dedicated config for sampling. I feel like the simplest solution here could be extending this check to ignore CheckInEvents as well. However, sample_rate affecting events other than errors was a bit surprising for us as well, so perhaps the docs could be improved to reflect this gotcha?
If you agree with my proposed solution, I'm happy to take a stab at submitting a patch.
As a workaround for now, we have removed the sample_rate config option and instead applied the same logic in before_send, but only for Exception events.
Reproduction Steps
Configure sample_rate to be below 1, instrument a worker with cron monitoring, and perform it a bunch of times
Issue Description
We are trialling the Cron Monitoring beta (which looks like a very promising product!), and have noticed a strangely erratic nature of our cron check ins: Sentry often reported them as timed out or missing when according to our data the scheduled workers ran on time and in reasonable time.
We also have set the
sample_rate
config option to0.25
to report fewer exceptions to Sentry.I followed the source code for capturing the CheckIn events and discovered that they are affected by the
sample_rate
parameter: https://github.com/getsentry/sentry-ruby/blob/master/sentry-ruby/lib/sentry/client.rb#L51-L54It appears that
TransactionEvent
is the only type ofEvent
that is not affected bysample_rate
, and is using its own dedicated config for sampling. I feel like the simplest solution here could be extending this check to ignoreCheckInEvent
s as well. However,sample_rate
affecting events other than errors was a bit surprising for us as well, so perhaps the docs could be improved to reflect this gotcha?If you agree with my proposed solution, I'm happy to take a stab at submitting a patch.
As a workaround for now, we have removed the
sample_rate
config option and instead applied the same logic inbefore_send
, but only for Exception events.Reproduction Steps
Configure
sample_rate
to be below 1, instrument a worker with cron monitoring, and perform it a bunch of timesExpected Behavior
All CheckIn events reach Sentry
Actual Behavior
CheckIn events are sampled
Ruby Version
3.2.2
SDK Version
5.15.1
Integration and Its Version
No response
Sentry Config
The text was updated successfully, but these errors were encountered: