Viewing historical queue depth

[barmstrong]

Is there a way to see what the queue depth was over time?

This would be very helpful for capacity planning, or to see when a cron job for example enqueued a large number of jobs and backed things up.

Sometimes we receive anecdotal bug reports that we believe are due to jobs being backed up, but by the time we view the queue things are cleared out.

[mperham]

We track the number of jobs processed in Librato Metrics. This graph uses Sidekiq Pro's statsd integration to push the numbers to Librato:

You could do something similar for queue depth or latency.

[seuros]

You could use a service like @newrelic or liberato to monitor your sidekiq workers .

[barmstrong]

Thanks for the info! This is tracking the number of jobs processed, but is it tracking queue depth?

[mperham]

@barmstrong Right now tracking queue depth or latency would need to be done outside of Sidekiq since there's no good place to do it in the Sidekiq code. The Sidekiq::Queue#{size,latency} API exposes those numbers so it's easy to sample via a cron job and send those numbers to your favorite metrics service.

[Notalifeform]

@mperham Having the number of processed jobs per queue would also be very helpful - I don't think that is currently recorded/exposed; is it?

[mperham]

It is not. I'm working with @davydovanton this summer to build a Sidekiq history gem which will track more metrics. These are more possible use cases for it.

[Notalifeform]

great to hear. I'm looking forward to that feature.

[davydovanton]

@Notalifeform, hello!
You can find sidekiq history project in this repository davydovanton/sidekiq-history (sorry this is GSoC project because that I don't accept any PR).
And if you have any proposals or ideas - I will happy if you share them 😃

[skwp]

https://github.com/phstc/sidekiq-statsd/blob/master/lib/sidekiq/statsd/server_middleware.rb seems to implement latency reporting. Is this not something sidekiq could do natively?

[mperham]

Sidekiq Enterprise will get this feature in 2016. See issue linked above.