Que

Que is a high-performance alternative to Delayed::Job or Queue Classic that improves the reliability of your application by protecting your jobs with the same ACID guarantees as the rest of your data. AppSignal instruments Que automatically when Que is detected on start, tracking exceptions and performance issues. No manual setup is required.

​

Performance monitoring

​

Event timeline

Que jobs appear in the event timeline of your application’s performance actions as perform_job.que events.

​

Incident grouping

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

​

Enqueue instrumentation

Enqueuing a Que job records an enqueue.que event, titled after the job being enqueued. Bulk enqueues on version 2 of Que record a single bulk_enqueue.que event instead. 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 Que integration is compatible with Active Job. Upgrade to version 2.11.0 of the Ruby gem or newer for improved support.

​

Example application

We have an example application in our examples repository on GitHub.

• AppSignal + Rails 5 + Que The example shows how to set up a Rails 5 app with Que monitored by AppSignal.

​

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. Jobs enqueued with Que.bulk_enqueue are the exception. They do not appear under the trace that enqueued them. Each job gets a trace of its own, linked back to the bulk enqueue, because one enqueue cannot be the parent of a whole batch. The trace is carried in the job’s tags. Que has tags from version 1.0 onwards, so nothing is carried on Que 0.x. Que allows at most five tags per job. A job with no room left for the trace is enqueued without one. Read more about distributed tracing.