Active Job

AppSignal for RubyThis feature requires 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

AppSignal for RubyThis feature requires version 3.7.3 or higher.

Active JobThis feature requires 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:

Metadata	Description
Active Job ID	The Active Job ID is reported by the Active Job adapter.
Arguments	Arguments passed to the job when calling `perform_later`.
Events	All `*.active_job` events.
Job name	e.g. `MyBackgroundJob#perform` as used to group the job for AppSignal incidents.
Priority	The sample's priority, if using an adapter that supports job priority.
Provider job ID	The job ID reported by the Active Job adapter.
Queue	The 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:

Metadata (excluding job name and events) will be available as filterable tags on incident samples:

*.active_job events will shown in the event timeline for performance samples:

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:

Graph	Metrics	Tags
Duration per job class	`transaction_duration`	`namespace` `action`
Job status per queue	`active_job_queue_job_count`	`status` `queue`
Job status per queue with priority	`active_job_queue_job_count`	`status` `queue` `priority`
Throughput per job class	`transaction_duration`	`namespace` `action`

Tags give you a contextual breakdown of Active job performance information, currently AppSignal reports the following tags for Active Job jobs:

Name	Description
`action`	The name of the action the metric was reported from (eg: `YourWorker#perform`).
`queue`	Named queue in which jobs are processed, e.g. `default` or `mailer`.
`status`	Status of each job, either `processed` or `failed`. Jobs that are `failed` are also counted as `processed`.
`priority`	The priority given to each job, e.g. `0` or `1`.

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

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.

Monitoring features

Supported Languages