Configuring Adapters for Judoscale Metrics Reporting

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

Web Processes
- Ruby: Rails, anything Rack-based
- Python: Django, Flask, FastAPI
- 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 adapter packages 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 package 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 package 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 package.

`JUDOSCALE_MAX_QUEUES`

This environment variable controls the maximum number of job/task queues that an adapter reports to Judoscale. We cap this to avoid reporting excessive queues, particularly for apps that generate queues on the fly.

The default JUDOSCALE_MAX_QUEUES value is 20. If you have more than 20 queues, set this variable higher in your platform config or use the max_queues option in your adapter configuration block (see the language-specific docs linked above) to avoid losing queue data.