Resque

Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later. AppSignal instruments Resque automatically when the Resque gem is detected on start. No manual setup is required.

​

Performance monitoring

​

Event timeline

Resque jobs appear in the event timeline of your application’s performance actions as perform.resque events.

​

Incident grouping

AppSignal detects job names from the Resque worker class name, suffixed with the perform method name, resulting in something like MyWorker#perform. AppSignal groups jobs by this name for performance monitoring and notifications.

​

Enqueue instrumentation

Enqueuing a Resque job records an enqueue.resque event, titled after the job being enqueued. 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.

​

Active Job support

The Resque integration is compatible with Active Job. Upgrade to version 2.11.0 of the Ruby gem or newer for improved support.

​

Example apps

We’ve added a Rails 5 + Resque example app to our examples repository. Take a look if you’re having trouble getting AppSignal for Resque configured.

​

Span attributes

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

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 on the job payload, alongside its class and arguments. Read more about distributed tracing.