Introduce sentry-good_job integration

[amkisko]

Overview

This PR introduces an integration for GoodJob that provides error capture with enriched context, performance monitoring, and cron monitoring for applications using GoodJob as their ActiveJob backend.

Features

Error Capture & Performance Monitoring

• Automatic exception capture from ActiveJob workers using GoodJob
• Performance monitoring with execution time and queue latency tracking
• Trace propagation across job executions
• Configurable error reporting (after retries, only dead jobs, etc.)

Cron Monitoring

• Automatic setup by reading GoodJob cron configuration
• Manual setup via sentry_cron_monitor method
• Timezone support for scheduled jobs

Configuration Options

• include_job_arguments: Control whether job arguments are included in error context (default: false)
• report_after_job_retries: Only report errors after all retry attempts (default: false)
• report_only_dead_jobs: Only report errors for jobs that cannot be retried (default: false)
• auto_setup_cron_monitoring: Automatically set up cron monitoring (default: true)
• logging_enabled: Enable detailed logging for debugging (default: false)

Architecture

• Unified JobMonitor class handling error capture, performance monitoring, and cron setup
• Separate components for error handling, logging, and cron monitoring
• Rails integration with automatic setup when GoodJob is detected

Production Testing

This integration is actively tested in production environments and handles:

• High-volume job processing without performance impact
• Proper error context capture while protecting sensitive data
• Reliable cron monitoring for scheduled jobs

Configuration Example

Sentry.init do |config|
  config.dsn = 'your-dsn-here'
  
  config.good_job.report_after_job_retries = false
  config.good_job.include_job_arguments = false
  config.good_job.auto_setup_cron_monitoring = true
  config.good_job.logging_enabled = false
end

Compatibility

• Ruby 2.4+
• Rails 5.2+
• Good Job 3.0+
• Sentry Ruby SDK 5.28.0+

Key Differences from Other Integrations

• Job arguments disabled by default (other integrations include them by default)
• Automatic cron monitoring setup from GoodJob configuration
• Centralized logging system with configurable loggers
• Unified monitoring architecture with separate error handling and cron components

[amkisko]

@bensheldon Hey! Thank you for reading the code.

• I'm not sure of the necessity of JobMonitor and ErrorHandler. Those seem like Active Job monitors, not GoodJob ones.

True, I was actually wondering how does sentry-sidekiq resolve this in situation when it is used as ActiveJob provider. Let's use sentry-rails implementation instead.

• I also think CronMonitor is arguably Active Job related, if the intention is to alert when a set of jobs fails to perform on a regular schedule (Cron Monitoring). GoodJob is the implementation, but that doesn't seem inherent to GoodJob.

ActiveJob does not have any relation to GoodJob scheduler (if it will be, then it should be under sentry-rails). CronMonitoring class is required for Sentry Cron monitors feature. That's one of much waited thing.

• On naming, I've intentionally avoided using "dead" in GoodJob because I think it's an inappropriate technical metaphor. If it can be avoided here, that would be nice.

This one will be fixed, thank you for clarification, I fully agree.

[amkisko]

@bensheldon if we keep it simple, then only cron feature support is required, but sentry-rails has very simple implementation on context enrichment, it takes only basic things from ActiveJob parameters. Might make sense separately improve sentry-rails implementation.

[amkisko]

Two weeks in production, works well!

[amkisko]

@solnic Hey! Could you give this PR another look and tell if there is any possible schedule getting this merged and released as public gem? Another option I can suggest — me releasing sentry-good_job gem using personal/company rubygems profile, as at the moment it leads to some unwanted issues during bundler usage.

[amkisko]

So at the moment have to do this in order to make things work:

gem "sentry-ruby", git: "https://github.com/amkisko/sentry-ruby.git", branch: "release", glob: "sentry-ruby/sentry-ruby.gemspec"
gem "sentry-rails", git: "https://github.com/amkisko/sentry-ruby.git", branch: "release", glob: "sentry-rails/sentry-rails.gemspec"
gem "sentry-good_job", git: "https://github.com/amkisko/sentry-ruby.git", branch: "release", glob: "sentry-good_job/sentry-good_job.gemspec"

release branch includes changes I would want to see in the gems (two pull requests here).

[amkisko]

@solnic Hey! Any actions required from my side according to findings in CI checks?

[amkisko]

Latest mainstream changes are here

[amkisko]

Hey! I am planning to release this as gem, it takes resources maintaining git-based gem sources, so would like to avoid this completely.

[amkisko]

Published here: https://rubygems.org/gems/sentry-good_job Source code here: https://github.com/amkisko/sentry-good_job

There are already changes that are not relevant to this Pull Request like additional markdown files and some other changes (according to my requirements).