Replies: 2 comments 3 replies
-
Thanks for opening this discussion! I agree that markdown tables are painful to generate. I'd like to avoid that if possible. I'm also fearful of documentation getting out of sync with implementation. The instrumentation events are (mostly) exercised by the Log Subscriber: https://github.com/bensheldon/good_job/blob/main/lib/good_job/log_subscriber.rb I wonder if the generated Log Subscriber documentation could be linked to: https://www.rubydoc.info/gems/good_job/GoodJob/LogSubscriber (rubydoc seems very unreliable, which also makes me wonder if we should self-host the generated yard docs) That would mean the Log Subscriber subscribing to all the events, even if they don't generate a log, but I think that's fine to have some noop methods. |
Beta Was this translation helpful? Give feedback.
-
Is any one used NewRelic with good_job |
Beta Was this translation helpful? Give feedback.
-
See #411.
Proposal for the new section. There's only one instrumentation event for now since I'll have to go over the code base and find all of them and I'd like to know if this is the direction we should be headed (also because markdown tables are a chore to generate).
Monitoring and instrumentation
GoodJob integrates with Rails' ActiveJob framework, which is instrumented and has existing monitoring tools, such as AppSignal, DataDog, NewRelic, Skylight etc.
In addition to that, GoodJob offers its own instrumentation:
enqueue_job.good_job
active_job
scheduled_at
create_with_advisory_lock
GoodJob::Execution
record after it is created.Beta Was this translation helpful? Give feedback.
All reactions