Troubleshooting

No Data

APM

Not seeing any data?

Using Heroku? View our Heroku-specific troubleshooting instructions.

i. Is monitoring enabled for your environment?

Sometimes this can be deliberately disabled for environments that you are intending to test.

1. Is there a log/scout_apm.log file?

Yes:

Examine the log file for error messages:

tail -n1000 log/scout_apm.log | grep "Starting monitoring" -A20

See something noteworthy? Proceed to to the last step (#step 7). Otherwise, continue to step 2.

No:

The gem was never initialized by the application.

Ensure that the scout_apm gem is not restricted to a specific group in your Gemfile. For example, the configuration below would prevent scout_apm from loading in a staging environment:

group :production do
  gem 'unicorn'
  gem 'scout_apm'
end

Jump to the last step (#step 7) if scout_apm is correctly configured in your Gemfile.

2. Set log_level: debug in your scout_apm.yml file, or SCOUT_LOG_LEVEL=debug if using environment variable, and restart your application.

Examine the log file for error messages:

tail -n1000 log/scout_apm.log

3. Was the **scout_apm** gem deployed with your application?

bundle list scout_apm

4. Did you download the config file, placing it in **config/scout_apm.yml**?

5. Did you restart the app and let it run for a while?

6. Are you sure the application has processed any requests?

tail -n1000 log/production.log | grep "Processing"

7. Using Unicorn?

Add the preload_app true directive to your Unicorn config file. Read more in the Unicorn docs.

8. Oops! Still not seeing any data? Check out the GitHub issues and send us an email with the following:

• Set log_level: debug in scout_apm.yml (SCOUT_LOG_LEVEL=debug if using environment variables)
• The last 1000 lines of your log/scout_apm.log file, if the file exists:
  tail -n1000 log/scout_apm.log.
• Your application’s gems bundle list.
• Rails version
• Application Server (examples: Passenger, Thin, etc.)
• Web Server (examples: Apache, Nginx, etc.)

We typically respond within a couple of hours during the business day.

Errors

One thing to note is that by default we don’t collect errors for ActiveRecord::RecordNotFound as well as ActionController::RoutingError.

To collect these error types you will need to set errors_ignored_exceptions to an empty array: SCOUT_ERRORS_IGNORED_EXCEPTIONS=[]

Significant time spent in “Controller” or “Job”

When viewing a transaction trace, you may see time spent in the “controller” or “job” layers. This is time that falls outside of Scout’s default instrumentation.

There are two options for gathering additional instrumentation:

1. Custom Instrumentation - use our API to instrument pieces of code that are potential bottlenecks.
2. Auto Instruments - Auto Instruments breaks down time spent within the controller layer. Note that Auto Instruments does not instrument background jobs.

Missing memory metrics

Memory allocation metrics require the following:

• Ruby version 2.1+
• scout_apm version 2.0+

If the above requirements are not met, Scout continues to function but does not report allocation-related metrics.

StackLevelTooDeep error

If you experience a StackLevelTooDeep error, this is due to the way different monitoring tools instrument into the various libraries.

When one library uses alias_method and another uses prepend depending on the order these gems are initialized, a circular loop can happen.

There are two ways to fix this:

1. make sure the scout_apm gem is listed in the Gemfile above the conflicting gem.

Fixes the StackLevelTooDeep Error:

gem 'scout_apm'
gem 'newrelic_rpm'

Causes StackLevelTooDeep Error:

gem 'newrelic_rpm'
gem 'scout_apm'

2. If this does not work, for Ruby agent versions greater than 5.3.0, set use_prepend: true in your config/scout_apm.yaml. For Heroku customers, set SCOUT_USE_PREPEND=true in your environment variables.

SimpleCov Conflict

When auto instruments is enabled in the test environment (most likely being set in the defaults section in your scout_apm.yml file), conflicts may arise with SimpleCov. To fix this issue, disable auto_instruments in the test environment in either your scout_apm.yml file or via environment variables.