-
-
Notifications
You must be signed in to change notification settings - Fork 501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sidekiq-cron
patch for automatic monitoring of jobs listed in the schedule
#2170
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2170 +/- ##
==========================================
+ Coverage 92.24% 97.37% +5.13%
==========================================
Files 88 98 +10
Lines 3468 3655 +187
==========================================
+ Hits 3199 3559 +360
+ Misses 269 96 -173
|
aaf2454
to
26c4a5d
Compare
sidekiq-cron
patch for automatic monitoring of jobs listed in the schedule
26c4a5d
to
1938d61
Compare
1ff8687
to
9c3ddc5
Compare
schedule * optional patch under `sidekiq_cron` * patch the `Sidekiq::Cron::Job#save` method and auto inject the Sentry::MonitorCheckIns module and turn monitoring on part of #2134
9c3ddc5
to
0699b8c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if perform
is actually being called for sidekiq which I assume you tested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't mind me, I was just catching up.
|
||
# only patch if not explicitly included in job by user | ||
unless klass_const.send(:ancestors).include?(Sentry::Cron::MonitorCheckIns) | ||
klass_const.send(:include, Sentry::Cron::MonitorCheckIns) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this make it so any invocation of the related Job class, including invocations triggered by sidekiq-cron
, and invocations that the user did manually, with just HappyWorkerJob.perform_async
? It looks like it would, right?
I wonder if there are situations when users want to kick the same job for a one-off thing that they don't want to be reported to Sentry. I, personally, think that since the defined sidekiq-cron
job just wraps a Sidekiq
job, than whenever that job was triggered, it should be reported.
Do we want to add this to docs? Is this behavior consistent with other languages and frameworks Sentry supports?
/cc @sl0thentr0py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add docs for all of this around releasing.
Would this make it so any invocation of the related Job class, including invocations triggered by sidekiq-cron, and invocations that the user did manually, with just HappyWorkerJob.perform_async? It looks like it would, right?
yes
I wonder if there are situations when users want to kick the same job for a one-off thing that they don't want to be reported to Sentry. I, personally, think that since the defined sidekiq-cron job just wraps a Sidekiq job, than whenever that job was triggered, it should be reported.
This is a new feature, we will add special config once people use it and request it. This is fine as a first version, it's an opt-in patch either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like there could be multiple ways to invoke save
in addition to the initial creation. Although the current implementation doesn't seem to have obvious performance impact, I feel a better place to inject such one-off activation logic is load_from_array
instead.
I understand that it's an experimental feature for now, so I'm not suggesting an immediate refactor. Just want to point it out for future improvements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if people are scheduling cron jobs with Sidekiq::Cron::Job.create
, we patch those too automatically, either way shouldn't matter, we can react to feedback from users later depending on usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honest question so I can draft the docs PR:
- to enable
sidekiq-cron
and/orsidekiq-scheduler
monitoring, the users will have to manually addconfig.enabled_patches += [:sidekiq_cron]
, right? - When this patch is applied, and as long as
sidekiq-cron
is indeed available, we aim to instrument all jobs that it runs, all the time. The current logic that hooks intosave
does that. Correct? - One side-iffect is that we're instrumenting the job class itself, so whether it was the
sidekiq-cron
schedule that invoked the job on a timer, or the user's code invokedperform_*
on that job, we will monitor that too. That's by design for now, but we'll keep an eye out for feedback. Right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes to all
- Adds support for `sidekiq-scheduler` instrumentation without any configuration from the user. - Based on getsentry#2170.
- Adds support for `sidekiq-scheduler` instrumentation without any configuration from the user. - Based on getsentry#2170.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long delay. I was preparing for and attending RubyConf in the US.
|
||
# only patch if not explicitly included in job by user | ||
unless klass_const.send(:ancestors).include?(Sentry::Cron::MonitorCheckIns) | ||
klass_const.send(:include, Sentry::Cron::MonitorCheckIns) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like there could be multiple ways to invoke save
in addition to the initial creation. Although the current implementation doesn't seem to have obvious performance impact, I feel a better place to inject such one-off activation logic is load_from_array
instead.
I understand that it's an experimental feature for now, so I'm not suggesting an immediate refactor. Just want to point it out for future improvements.
* Crons: add sidekiq-scheduler zero config support. - Adds support for `sidekiq-scheduler` instrumentation without any configuration from the user. - Based on #2170. * Crons: support intervals for sidekiq-scheduler jobs - AppliesApply review feedback. - Adds support for interval and every interval_types for sidekiq-scheduler-schedule - Adds specs for the above. * Crons: changelog for sidekiq-scheduler support. * Crons: fix tests on Sidekiq 6 * Require sidekiq-scheduler to ensure it's there * sidekiq-scheduler mock config without delegation * Make version checks consistent * Fix some stuff * need int for interval * constantize doesn't exist outside rails * cleanup specs --------- Co-authored-by: Neel Shah <neelshah.sa@gmail.com>
We use a different file (i.e. not |
Yep. It doesn’t care where the schedule comes from.
|
sidekiq_cron
Sidekiq::Cron::Job#save
method and auto inject theSentry::MonitorCheckIns
module and turn monitoring onpart of #2134