Sidekiq DelayedModel


NewRelic is reporting stats from my Rails application jsut fine for the most part, but there is one place that the stats are misleading and that’s reporting on the Sidekiq DelayedModel extension:

This extension allows you to arbitrarily delay certain code to run later in a background job by calling delay, for instance contact_list.delay.clear_assignments.

This creates an “anonymous” background job which is later run as a regular named background job would be. Unfortunately NewRelic logs every single one of these as:


no matter where in the code it is called from. It is almost impossible to use the information logged to actually make any changes to the codebase because the location the code is originally called from is lost, and it’s not always possible to work out what actual task was being run from the trace.

Does anyone have any advice for separating these jobs out/grouping them better in the UI?



Thank you for the great context here.

First, if you haven’t already, you can enable the Sidekiq instrumentation in the newrelic.yml file:

This is disabled by default, and you may want to check that there is no sensitive information in your job arguments before enabling this. You will need to restart you application after making any configuration changes.

Second, have you reviewed the troubleshooting guide over here in the Delayed::Job instrumentation?

It seems like it may be expecting it to end in delayed_job here.

I hope this helps! If not, we would like a permalink to your application view.
This link it not followable by anyone other than you or our support staff. That might help us to dig into your specific environment page.

In order to create a permalink to any page within the New Relic user interface, scroll to the bottom and click ‘Permalink’ all the way on the right next to ‘Kiosk Mode.’ This will show us the exact page and time period that you are observing.

We look forward to looking further into this with you.

Hi @michaelbrooks,

It looks from that first link the only extra configuration documented there is to enable the capturing of job parameters, and that Sidekiq is instrumented by default. We are in fact seeing Sidekiq job instrumentation, and we don’t need to capture the parameters right now, so that link doesn’t seem relevant to us.

The second link is relevant to the Delayed::Job background job processor, something we are not using, and in fact unrelated to Sidekiq.

Here’s a link to a problem transaction as described:

@will16 ,

Thank you for the permalink! That is often our clearest picture into the ask and your environment.

If you dig down into your trace you can see for more information you’ll need to use custom metrics:

Here are the two docs the UI help prompt is referring to and should get you on your way to utilizing all of the details of your build! :smiley:

Let us and the community know how this works out for you so we can help others in the process :heart:

1 Like