Skip to main content
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 Intelligence 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, these adapters have not been tested. Adapters without a dedicated AppSignal integration are monitored through Active Job instrumentation, such as GoodJob.

​
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

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.
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.

​
Enqueue instrumentation

Enqueuing a job through Active Job records an enqueue.active_job event, titled after the job being enqueued. When a job is enqueued through an adapter that AppSignal also instruments, such as Sidekiq or Resque, AppSignal suppresses the adapter’s own enqueue event and records the enqueue once as the Active Job event. AppSignal records enqueue events on the active transaction’s event timeline, for example when you enqueue a job from within a web request or from within another job. It only records them when a transaction is active, so enqueuing a job outside of a transaction records nothing. To stop recording enqueue events across all background job integrations, set the enable_job_enqueue_instrumentation config option to false. This does not affect the instrumentation of the jobs themselves.

​
Metadata

AppSignal collects the following metadata for Active Job jobs: *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 traces 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 traces:
Example Active Job tags
  • *.active_job events will be shown in the event timeline for performance traces:
Example Event timeline

​
Intelligence dashboard

When AppSignal receives Active Job metrics, it will create an Active Job Intelligence dashboard, available from the dashboard section of the AppSignal app. The Active Job Intelligence dashboard will have the following graphs: Tags give you a contextual breakdown of Active Job performance information. AppSignal reports the following tags for Active Job jobs: Each tag will be represented with a colored line on the graph: Example Active 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 graph shows the number of jobs that were executed, grouped by their resulting status and 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.

​
Span attributes

Collector mode only: this applies when AppSignal for Ruby runs in collector mode. It has no effect otherwise.
The enqueue and the job’s own span both carry:
  • messaging.system — the queueing library.
  • messaging.destination.name — the queue the job was put on.
  • messaging.operation.type — whether the span is the enqueue or the job running.
A span for a job that raised also carries error.type, the class of the error.

​
Distributed tracing

Collector mode only: this applies when AppSignal for Ruby runs in collector mode. It has no effect otherwise.
A job runs in the same trace as the code that enqueued it, appearing under the request or job that scheduled it. You can trace a slow job back to what caused it to run. The trace is carried in the job’s serialized arguments. Active Job runs on a queue adapter. When that adapter is one AppSignal instruments, such as Sidekiq or Resque, its own behavior applies as well. Read more about distributed tracing.