Active Job

This feature requires AppSignal for Ruby version 2.11.0 or higher.

Active Job is a framework for declaring jobs and making them run on a variety of queuing backends shipped with Rails.

The Active Job integration tracks the execution and events from the job being performed.

When AppSignal detects Active Job metrics, it will create an Automated Dashboard, allowing you to monitor core metrics visually.

Supported adapters

The Active Job integration supports all Active Job adapters.

It may also offer support for adapters not listed on that page, which are accessible through a separate gem. However, please note that these adapters have not been tested.

Integration with AppSignal-supported libraries

The following background job libraries that AppSignal supports are automatically integrated with Active Job, allowing AppSignal to give you more in-depth performance insights:

Report errors on job discard

This feature requires AppSignal for Ruby version 3.7.3 or higher.
This feature requires Active Job version 7.1.0 or higher.

Set the activejob_report_errors config option to discard to only report errors when a job is discarded. When a job is discarded, all job retries have been exhausted, and the job is no longer retried. Read the Active Job documentation to learn more about Active Job exception handling and failed job retries.

ruby
class ExampleJob < ActiveJob::Base # Configure the retry attempts using the `retry_on` method retry_on StandardError, :attempts => 2 # ... end

Some Active Job adapters (such as Sidekiq, Delayed::Job, etc.) have their own retry system. After Active Job has exhausted its retries, these libraries may trigger their own job retry system.

This will retry jobs even after it has exhausted the Active Job retries and discarded the job. To avoid retrying jobs after Active Job has stopped retrying the job, and it reporting errors for those retries, make sure the adapter's retry system is disabled.

When relying on Sidekiq's retry system, also configure it to report errors only on discard, so that it won't report errors multiple times.

Metadata

AppSignal collects the following metadata for Active Job jobs:

MetadataDescription
Active Job IDThe Active Job ID is reported by the Active Job adapter.
ArgumentsArguments passed to the job when calling perform_later.
EventsAll *.active_job events.
Job namee.g. MyBackgroundJob#perform as used to group the job for AppSignal incidents.
PriorityThe sample's priority, if using an adapter that supports job priority.
Provider job IDThe job ID reported by the Active Job adapter.
QueueThe sample's queue name, if using an adapter that supports multiple queues.
Queue time*Time elapsed from a job being queued and performed.

*From Rails version 6 onwards queue times are reported for the namespace they are reported from and can be viewed in AppSignal's Performance Graphs.

AppSignal uses Active Job metadata to give you deeper contextual insights into job performance. When inspecting Active Job samples in AppSignal:

  • The Job name will be used to group the job for AppSignal incidents:
Example performance issues overview
  • Metadata (excluding job name and events) will be available as filterable tags on incident samples:
Example Active Job tags
  • *.active_job events will shown in the event timeline for performance samples:
Example Event timeline

Automated dashboard

When AppSignal receives Active Job metrics, it will create an Active Job automated dashboard, available from the dashboard section of the AppSignal app.

The Active Job automated dashboard will have the following graphs:

GraphMetricsTags
Duration per job classtransaction_duration
  • namespace
  • action
  • Job status per queueactive_job_queue_job_count
  • status
  • queue
  • Job status per queue with priorityactive_job_queue_job_count
  • status
  • queue
  • priority
  • Throughput per job classtransaction_duration
  • namespace
  • action
  • Tags give you a contextual breakdown of Active job performance information, currently AppSignal reports the following tags for Active Job jobs:

    NameDescription
    actionThe name of the action the metric was reported from (eg: YourWorker#perform).
    queueNamed queue in which jobs are processed, e.g. default or mailer.
    statusStatus of each job, either processed or failed.
    Jobs that are failed are also counted as processed.
    priorityThe priority given to each job, e.g. 0 or 1.

    Each tag will be represented with a colored line on the graph:

    Example Actie Job dashboard

    Duration per job class graph

    The Duration per job class graph shows the amount of time that it took for jobs to execute, grouped by the class that defines the job.

    You can use this graph to monitor the performance of jobs, per class, giving you a helicopter view of job performance and allowing you to quickly identify and investigate spikes in duration time.

    Job status per queue graph

    The Job status per queue with priority graph shows the number of jobs that were executed, grouped by their resulting status, by the queue in which they were enqueued.

    You can use this graph to monitor job error counts and performance based on queue, identify bottlenecks, and optimize your background jobs for scalability.

    Job status per queue with priority graph

    Not all Active Job adapters support job priority. If jobs have no priority values, the graph will be empty.

    The Job status per queue with a priority graph shows the number of jobs that were executed, grouped by their resulting status by the queue in which they were enqueued, and by the priority that was given to them.

    You can use this graph to monitor job error counts and performance based on queue and priority identify bottlenecks, and optimize your background jobs for scalability.

    Throughput per job class graph

    The Throughput per job class graph shows the amount of jobs that were executed, grouped by the class that defines the job.

    You can use this graph to monitor how many jobs are executed, grouped by the class that defines the job.