Classes with #perform methods
Delayed Job supports enqueuing jobs based on instances of classes or structs that listen to a perform instance method, when enqueued with Delayed::Job.enqueue. AppSignal will use the object’s class name as the action naming, appending #perform to the action name. A job for StructJob is reported as StructJob#perform.
id for the StructJob in the example above is not reported.
Jobs using display_name
Delayed Job allows any class to define its own display_name. This display_name value can interfere with AppSignal’s reporting if it is built using dynamic values, such as the arguments given to the job.
If the display_name method return value does not return a String with the ClassName#method_name format, AppSignal treats each job as a separate entity, creating many Incidents and notifications. This breaks the grouping AppSignal does for these jobs, resulting in AppSignal reporting many unique variations of incidents for the job, and unusable metrics in graphs.
To prevent this from happening, define an appsignal_name method that returns a job name using the ClassName#method_name format. This way the jobs will be grouped correctly again.
Delay method call support
Method calls queued with the delay extension will be reported with an action name similar to how they are called. The arguments given to the delayed method will be reported as the arguments for the job.Delayed::Job.enqueue support
Custom jobs objects enqueued withDelayed::Job.enqueue will be reported as normal, but will not report arguments. A whole object is given to Delayed::Job, and serialized into YAML and back. We can’t detect arguments in this scenario.
Enqueue instrumentation
Enqueuing a job with Delayed::Job records anenqueue.delayed_job event, titled after the job being enqueued. If a job defines an appsignal_name, the enqueue event uses it, the same way the performed job’s action name does.
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 Delayed Job integration is compatible with Active Job. It will report queue times in graphs, queues and priorities if set on the job. Upgrade to version 2.11.0 of the Ruby gem or newer for improved support.Changes to the integration
Queue time
In AppSignal for Ruby gem 2.3.0 a change was made to the queue time registration. In PR #297 the start time of the job was used rather than the creation time of the job. This means that the time from when a job was created until the time it should start is no longer registered as queue time. This will prevent very long queue times from skewing the queue time graphs on AppSignal.com.Example applications
Below is a list of example apps available to test the Delayed::Job integration with:- AppSignal + Rails 5 + Delayed::Job
- The example shows how to set up AppSignal with Delayed::Job and Rails. In the
READMEfile it lists all known and tested methods of enqueuing jobs that AppSignal supports.
- The example shows how to set up AppSignal with Delayed::Job and Rails. In the
Span attributes
Collector mode only: this applies when AppSignal for Ruby runs in collector mode. It has no effect otherwise.
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.
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.