Configuring Adapters for Judoscale Metrics Reporting

Judoscale currently supports adapters for these web frameworks and job backends:

Web Processes
- Ruby: Rails, anything Rack-based
- Python: Django, Flask
- NodeJS: Express, Fastify
Background Job Processes
- Ruby: Sidekiq, Solid Queue, Resque, Delayed Job, Good Job, Que, Shoryuken in Rails or Rack-based
- Python: Celery, RQ
- NodeJS: Bull, BullMQ

Common Configs

Our adapters have a few common configuration options used to control the way these adapters report metrics to Judoscale. How you specify these options depends on the adapter you are using:

`JUDOSCALE_URL`

This is the one required environment variable. For Heroku apps, our add-on manages JUDOSCALE_URL for you automatically. On all other platforms, we provide this value for you in our setup wizard.

Note that JUDOSCALE_URL is usually—but not always—shared amongst services in an environment or cluster.

`JUDOSCALE_LOG_LEVEL`

If you find the Judoscale adapter too noisy in your logs, or if you need more verbose logging to troubleshoot an issue, this is the setting you want.

Set JUDOSCALE_LOG_LEVEL to “DEBUG” to enable debug logging. This will log the queue time capture for every request to your app, and provide more details each time the reporter posts metrics to the Judoscale API.

Set JUDOSCALE_LOG_LEVEL to “WARN” to quiet down some of the informational logging. Note that this can make it more difficult to troubleshoot issues with the adapter.

`MAX_QUEUES`

This setting controls the maximum number of job/task queues that the adapter will report to Judoscale. We have this in place to avoid reporting excessive queues, particularly for apps that generate queues on the fly.

The default MAX_QUEUES value is 20. If you have more than 20 queues, you will need to set this value to a higher number to avoid losing queue data. Use the language-specific links at the top of this document to learn how to set this value.