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 to 0.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-L54
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
Expected 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
Sentry.init do |config|
config.sample_rate = 0.25
config.enabled_patches += [:sidekiq_scheduler]
end
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_rateconfig option to0.25to report fewer exceptions to Sentry.I followed the source code for capturing the CheckIn events and discovered that they are affected by the
sample_rateparameter: https://github.com/getsentry/sentry-ruby/blob/master/sentry-ruby/lib/sentry/client.rb#L51-L54It appears that
TransactionEventis the only type ofEventthat 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 ignoreCheckInEvents as well. However,sample_rateaffecting 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_rateconfig option and instead applied the same logic inbefore_send, but only for Exception events.Reproduction Steps
Configure
sample_rateto 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