NAV

Scout APM Help Docs

Welcome to the help site for Scout Application Monitoring. Don’t have an account? Get started with a free trial.

Browse through the sidebar, search, or ask a question. We’re here to help.

Looking for our server monitoring help? Goto help.scoutapp.com.

Overview

Scout Application Monitoring is a lightweight, production-grade application monitoring service built for modern development teams. Just embed our agent in your application: we handle the rest.

Here’s an overview of the key functionality in our application monitoring service:

The Agent

We currently monitor Ruby on Rails apps, with beta support for Java (see java instructions here). Support for other languages and frameworks is under development.

Our agent is designed to run in production environments and has low overhead. Every minute, the agent transmits metrics to our service over SSL.

There’s nothing to install on your servers: just include our Ruby Gem within your Rails app. You’ll quickly see actionable metrics from the common libraries we instrument.

User Interface

A complete overview of the Scout UX is available in the features area of this help site.

Configuration

Requirements

Monitoring

Scout currently supports Ruby on Rails 2.2+ and Ruby 1.8.7+ and the following app servers/background job frameworks:

Memory Bloat detection and ScoutProf require Ruby 2.1+.

Git Integration - Optional

Viewing your application code within Scout requires that your source code is hosted at Github.com.

Installation

Tailored instructions are provided within our user interface. General instructions:

1

Your Gemfile:

gem 'scout_apm'

Shell:

bundle install
2

Download your customized config file, placing it at config/scout_apm.yml.

3

Deploy.

Updating to the Newest Version

The latest version of scout_apm is SEE CHANGELOG.

1

Ensure your Gemfile entry for Scout is: gem 'scout_apm'

2

Run bundle update scout_apm

3

Re-deploy your application.

The gem version changelog is available here.

Configuration Options

Scout APM can be configured via the config/scout_apm.yml Yaml file and/or environment variables. A config file with your organization key is available for download as part of the install instructions.

ERB evaluation

ERB is evaluated when loading the config file. For example, you can set the app name based on the hostname:

common: &defaults
  name: <%= "ProjectPlanner.io (#{Rails.env})" %>

Configuration Reference

The following configuration settings are available:

Setting Name Description Default Required
name Name of the application (ex: ‘Photos App’). Rails.application.class.to_s. sub(/::Application$/, '') Yes
key The organization API key. Yes
monitor Whether monitoring should be enabled. false No
log_level The logging level of the agent. INFO No
log_file_path The path to the scout_apm.log log file directory. Use stdout to log to STDOUT. Environment#root+log/ or STDOUT if running on Heroku. No
hostname The hostname the metrics should be aggregrated under. Socket.gethostname No
proxy Specify the proxy URL (ex: https://proxy) if a proxy is required. No
host The protocol + domain where the agent should report. https://apm.scoutapp.com No
uri_reporting By default Scout reports the URL and filtered query parameters with transaction traces. Sensitive parameters in the URL will be redacted. To exclude query params entirely, use path. filtered_params No
disabled_instruments An Array of instruments that Scout should not install. Each Array element should should be a string-ified, case-sensitive class name (ex: ['Elasticsearch','HttpClient']). The default installed instruments can be viewed in the agent source. [] No
ignore An Array of web endpoints that Scout should not instrument. Routes that match the prefixed path (ex: ['/health', '/status']) will be ignored by the agent. [] No
dev_trace Indicates if DevTrace, the Scout development profiler, should be enabled. Note this setting only applies to the development environment. false No
profile Indicates if ScoutProf, the Scout code profiler, should be enabled. true No

Environment Variables

You can also configure Scout APM via environment variables. Environment variables override settings provided in scout_apm.yml.

Environment variables have the same names as those in the Yaml config file, but are prefixed with SCOUT_. For example, to set the organization key via environment variables:

export SCOUT_KEY=YOURKEY

Deploy Tracking

Scout can track deploys, making it easier to correlate changes in your app to performance. To enable deploy tracking, first ensure you are on the latest version of scout_apm. See our upgrade instructions.

Scout identifies deploys via the following:

  1. If you are using Capistrano, no extra configuration is required. Scout reads the contents of the REVISION and/or revisions.log file and parses out the SHA of the most recent release.
  2. If you are using Heroku, enable Dyno Metadata. This adds a HEROKU_SLUG_COMMIT environment variable to your dynos, which Scout then associates with deploys.
  3. If you are deploying via a custom approach, set a SCOUT_REVISION_SHA environment variable equal to the SHA of your latest release.
  4. If the app resides in a Git repo, Scout parses the output of git rev-parse --short HEAD to determine the revision SHA.

Request Queuing

Scout can measure the time it takes a request to reach your Rails app from farther upstream (a load balancer or web server). This appears in Scout as “Request Queuing” and provides an indication of your application’s capacity. Large request queuing time is an indication that your app needs more capacity.

request queuing

To see this metric within Scout, you need to configure your upstream software, adding an HTTP header that our agent reads. This is typically a one-line change.

HTTP Header

The Scout agent depends on an HTTP request header set by an upstream load balancer (ex: HAProxy) or web server (ex: Apache, Ngnix).

Protip: We suggest adding the header as early as possible in your infrastructure. This ensures you won’t miss performance issues that appear before the header is set.

The agent will read any of the following headers as the start time of the request:

%w(X-Queue-Start X-Request-Start X-QUEUE-START X-REQUEST-START x-queue-start x-request-start)

Include a value in the format t=MICROSECONDS_SINCE_EPOCH where MICROSECONDS_SINCE_EPOCH is an integer value of the number of microseconds that have elapsed since the beginning of Unix epoch.

Nearly any front-end HTTP server or load balancer can be configured to add this header. Some examples are below.

Apache

Apache’s mod_headers module includes a %t variable that is formatted for Scout usage. To enable request queue reporting, add this code to your Apache config:

RequestHeader set X-Request-Start "%t"

HAProxy

HAProxy 1.5+ supports timestamped headers and can be set in the frontend or backend section. We suggest putting this in the frontend to get a more accurate number:

http-request set-header X-Request-Start t=%Ts

Nginx

Nginx 1.2.6+ supports the use of the #{msec} variable. This makes adding the request queuing header straightforward.

General Nginx usage:

proxy_set_header X-Request-Start "t=${msec}";

Passenger 5+:

passenger_set_header X_REQUEST_START "t=${msec}";

Older Passsenger versions:

passenger_set_cgi_param X_REQUEST_START "t=${msec}";

ActionController::Metal

Scout instruments controllers that inherit from ActionController::Base automatically, but not those that inherit from ActionController::Metal (including ActionController::API). We instrument ActionController::Base as this allows us to instrument the full request cycle (which includes before/after filters). If we just instrumented ActionController::Metal, we’d miss this instrumentation.

However, adding instrumentation to controllers that inherit from ActionController::Metal is simple. Just include our instrumentation library in the controller:

class FastController < ActionController::Metal
  include ScoutApm::Instruments::ActionControllerRails3Rails4Instruments

This won’t interfere with our regular instrumentation. Your controller-action metrics will appear under the endpoints area of Scout, just like any other controller-action.

Docker

Scout runs within Docker containers without any special configuration.

It’s common to configure Docker containers with environment variables. Scout can use enviornment variables instead of the scout_apm.yml config file.

Heroku

Scout runs on Heroku without any special configuration. When Scout detects that an app is being served via Heroku:

Configuration

Scout can be configured via environment variables. This means you can use heroku config:set to configure the agent. For example, you can set the application name that appears in the Scout UI with:

heroku config:set SCOUT_NAME='My Heroku App'

See the configuration section for more information on the available config settings and environment variable functionality.

Using the Scout Heroku Add-on

Scout is also available as a Heroku Add-on. The add-on automates setting the proper Heroku config variables during the provisioning process.

Cloud Foundry

Scout runs on Cloud Foundry without any special configuration.

We suggest a few configuration changes in the scout_apm.yml file to best take advantage of Cloud Foundry:

  1. Set log_file_path: STDOUT to send your the Scout APM log contents to the Loggregator.
  2. Use the application name configured via Cloud Foundry to identify the app.
  3. Override the hostname reported to Scout. Cloud Foundry hostnames are dynamically generated and don’t have any meaningful information. We suggest using a combination of the application name and the instance index.

A sample config for Cloud Foundry that implements the above suggestions:

common: &defaults
  key: YOUR_KEY
  monitor: true
  # use the configured application name to identify the app.
  name: <%= ENV['VCAP_APPLICATION'] ? JSON.parse(ENV['VCAP_APPLICATION'])['application_name'] : "YOUR APP NAME (#{Rails.env})" %>
  # make logs available to the Loggregator
  log_file_path: STDOUT
  # reports w/a more identifiable instance name using the application name and instance index. ex: rails-sample.0
  hostname: <%= ENV['VCAP_APPLICATION'] ? "#{JSON.parse(ENV['VCAP_APPLICATION'])['application_name']}.#{ENV['CF_INSTANCE_INDEX']}"  : Socket.gethostname %>

production:
  <<: *defaults

development:
  <<: *defaults
  monitor: false

test:
  <<: *defaults
  monitor: false

staging:
  <<: *defaults

Instrumented Libraries

The following libraries are currently instrumented:

Additionally, Scout can also instrument request queuing time.

Adding Custom Context

Context lets you see the forest from the trees. For example, you can add custom context to answer critical questions like:

It’s simple to add custom context to your app. There are two types of context:

User Context

For context used to identify users (ex: email, name):

ScoutApm::Context.add_user({})

Examples:

ScoutApm::Context.add_user(email: @user.email)
ScoutApm::Context.add_user(email: @user.email, location: @user.location.to_s)

General Context

ScoutApm::Context.add({})

Examples:

ScoutApm::Context.add(account: @account.name)
ScoutApm::Context.add(database_shard: @db.shard_id, monthly_spend: @account.monthly_spend)

Default Context

Scout reports the Request URI and the user’s remote IP Address by default.

Context Types

Context values can be any of the following types:

Context Field Name Restrictions

Custom context names may contain alphanumeric characters, dashes, and underscores. Spaces are not allowed.

Attempts to add invalid context will be ignored.

Example: adding the current user’s email as context

Add the following to your ApplicationController class:

before_filter :set_scout_context

Create the following method:

def set_scout_context 
    ScoutApm::Context.add_user(email: current_user.email) if current_user.is_a?(User)
end

Example: adding the monthly spend as context

Add the following line to the ApplicationController#set_scout_context method defined above:

ScoutApm::Context.add(monthly_spend: current_org.monthly_spend) if current_org

Environments

It typically makes sense to treat each environment (production, staging, etc) as a separate application within Scout and ignore the development and test environments. Configure a unique app name for each environment as Scout aggregrates data by the app name.

There are 2 approaches:

1. Modifying your scout_apm.yml config file

Here’s an example scout_apm.yml configuration to achieve this:

common: &defaults
  name: <%= "YOUR_APP_NAME (#{Rails.env})" %>
  key: YOUR_KEY
  log_level: info
  monitor: true

production:
  <<: *defaults

development:
  <<: *defaults
  monitor: false

test:
  <<: *defaults
  monitor: false

staging:
  <<: *defaults

2. Setting the SCOUT_NAME environment variable

Setting the SCOUT_NAME and SCOUT_MONITOR environment variables will override settings settings your scout_apm.yml config file.

To isolate data for a staging environment: SCOUT_NAME="YOUR_APP_NAME (Staging)".

To disable monitoring: SCOUT_MONITOR=false.

See the full list of configuration options.

Disabling a Node

To disable Scout APM on any node in your environment, just set monitor: false in your scout_apm.yml configuration file on that server, and restart your app server. Example:

common: &defaults
  name: <%= "YOUR_APP_NAME (#{Rails.env})" %>
  key: YOUR_KEY
  log_level: info
  monitor: false

production:
  <<: *defaults

Since the YAML config file allows ERB evaluation, you can even programatically enable/disable nodes based on host name. This example enables Scout APM on web1 through web5:

common: &defaults
  name: <%= "YOUR_APP_NAME (#{Rails.env})" %>
  key: YOUR_KEY
  log_level: info
  monitor: <%= Socket.gethostname.match(/web[1..5]/) %>

production:
  <<: *defaults

Aft you’ve disabled a node in your configuration file and restarted your app server, the node show up as inactive in the UI after 10 minutes.

Troubleshooting

No Data

Not seeing any data?

1

Is there a log/scout_apm.log file?

If not, the gem was never initialized by the application. Jump to the last step.
If there is a file, examine the file for any error messages:

tail -n1000 log/scout_apm.log | grep "Starting monitoring" -A20
See something noteworthy? Proceed to to the last step.

2

Using Unicorn?

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

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?

6

Are you sure the application has processed any requests?

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

Are your controllers inheriting from ActionController::Metal instead of ActionController::Base?

Add instrumentation to your ActionController::Metal controllers.

8

Oops! Looks like messed up. Send us an email with the following:

  • The last 1000 lines of your log/scout_apm.log file: 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.

Missing memory metrics

Memory allocation metrics are available version 2.0 of our agent, which is in BETA. To add memory metrics, modify your Gemfile entry for Scout:

gem 'scout_apm', '~> 2.0.x'

Then run bundle update scout_apm and deploy.

Service Status

We’re transparent about our uptime and service issues. If you appear to be experiencing issues with our service:

Contacting Support

Don’t hesitate to contact us at support@scoutapp.com any issues. We typically respond in a couple of hours during the business day.

Features

Scout is Application Monitoring built for modern development teams. It’s built to provide the fastest path to a slow line-of-code. Signup for a free trial.

App Performance Overview

The overview page provides an at-a-glance, auto-refreshing view of your app’s performance and resource usage (mean response time by category, 95th percentile response time, throughput, error rate, and more). You can quickly dive into endpoint activity via click-and-drag (or pinch-and-expand with a mobile device) on the overview chart.

overview

Additionally, you can compare metrics in the overview chart and see how your app’s performance compares to different time periods.

Endpoint Details

You can view metrics for specific controller-action and background job workers. There is a similar chart interaction to the App Performance Overview page, with one difference: your selection will render an updated list of transaction traces that correspond to the selected time period: stream

You can sort traces by response time, object allocations, date, and more.

Transaction Traces

Scout collects detailed transactions across your endpoints automatically. The transaction traces provide a number of visual queues to direct you to hotspots. Dig into bottlenecks - down to the line-of-code, author, commit date, and deploy time - from this view.

transaction traces

Call Breakdown

Method calls are aggregrated together and listed from most expensive to least expensive. The time displayed is the total time across all calls (not the time per-call).

stream show breakdown

SQL Queries

Scout captures a santized version of SQL queries. Click the “SQL” button next to a call to view details.

stream show sql

Don’t see the query next to an SQL call?

For performance reasons, Scout doesn’t attempt to sanitize large SQL queries. When this occurs, you won’t see an “SQL” button to view the raw query next to an SQL method call.

Code Backtraces

You’ll see “CODE” buttons next to method calls that are >= 500 ms. If you’ve enabled the Github integration, you can see the line-of-code, associated SQL or HTTP endpoint (if applicable), author, commit date, and deploy time for the relevant slow code.

stream show git

If you don’t enable the Github integration, you’ll see a backtrace.

ScoutProf

Every millisecond, ScoutProf captures a backtrace of what each thread in your application is currently running. Over many backtraces, when you combine them, it tells a story of what code paths are taking up the most time in your application.

Compared with our more traditional instrumentation of libraries like ActiveRecord, Net::HTTP and similar, ScoutProf works with your custom code. Now, when your application spends time processing your data in custom application code, or in libraries that Scout doesn’t yet instrument, instead of only being able to assign that to a large bucket of ActionController time, the time can be broken down to exactly what is taking up the most time.

Notice how the time in ActionController is broken down:

scoutprof

We still employ our traditional instrumentation, because it can give us deeper insights into common libraries, capturing the SQL being run, or the URL being fetched.

Enabling ScoutProf

ScoutProf is a BETA feature. To enable:

1

Modify your Gemfile entry for scout_apm, changing it to: gem 'scout_apm', '~> 3.0.x'

2

bundle update scout_apm

3

Deploy

A detailed ScoutProf FAQ is available in our reference area.

Memory Bloat Detection

If a user triggers a request to your Rails application that results in a large number of object allocations (example: loading a large number of ActiveRecord objects), your app may require additional memory. The additional memory required to load the objects in memory is released back very slowly. Therefore, a single memory-hungry request will have a long-term impact on your Rails app’s memory usage.

There are 3 specific features of Scout to aid in fixing memory bloat.

Memory Bloat Insights

The Insights area of the dashboard identifies controller-actions and background jobs that have triggered significant memory increases. An overview of the object allocation breakdown by tier (ActiveRecord, ActionView, etc) is displayed on the dashboard.

memory insights

Memory Traces

When inspecting a transaction trace, you’ll see a “Memory Allocation Breakdown” section:

memory trace

For perspective, we display how this trace’s allocations compare to the norm.

Sorting

You can sort by memory allocations throughout the UI: from the list of endpoints, to our pulldowns, to transaction traces.

memory sort

Git Integration

If your code is hosted at Github, you can see the relevant slow line-of-code within the Scout user interface when viewing a transaction trace. Additionally, you’ll also see the:

Git integration must be configured on the settings page for each app. Scout integrates with Github via OAuth. Pick the repository name and branch name used for your application.

git settings

Context

Context lets you see the forest from the trees. For example, you can add custom context to answer critical questions like:

Adding custom context is easy - learn how.

When viewing a transaction trace, click the “Context” section to see the context Scout has collected.

Endpoints Performance

Endpoints Overview

The endpoints area within Scout provides a sortable view of your app’s overall performance aggregated by endpoint name. Click on an endpoint to view details.

endpoints overview

Time Comparisons

You can easily compare the performance of your application between different time periods via the time selection on the top right corner of the UI.

time compare

DevTrace

DevTrace is our development profiler: it’s included with the scout_apm gem and can be used for free without signup. Enabling DevTrace adds a speed badge when navigating your Rails app in development. Clicking the speed badge reveals a shareable transaction trace of the request.

devtrace

Enabling DevTrace

DevTrace is a BETA feature. To enable:

  1. Ensure you are on the latest version of scout_apm. See our upgrade instructions.
  2. Add dev_trace: true to the development section of your scout_apm.yml config file or start your local Rails server with: SCOUT_DEV_TRACE=true rails server.
1

Ensure you are on the latest version of scout_apm. See our upgrade instructions.

2

Add dev_trace: true to the development section of your scout_apm.yml config file or start your local Rails server with: SCOUT_DEV_TRACE=true rails server.

Data Retention

Scout stores 30 days of metrics and seven days of transaction traces.

Reference

How we collect metrics

Scout is engineered to monitor the performance of your mission-critical production applications by providing an easy-install, low-overhead monitoring agent with a hosted SaaS service that values your security. The basic flow:

Performance Overhead

Our agent is designed to run in production environments and is extensively benchmarked to ensure it performs on high-traffic applications.

Our most recent benchmarks (lower is better):

overhead

We’ve open-sourced our benchmarks so you can test on our own. If your results differ, reach out to us at support@scoutapp.com.

Security

We take the security of your code metrics extremely seriously. Keeping your data secure is fundamental to our business. Scout is nearing a decade storing critical metrics with our server monitoring product and those same fundamentals are applied here:

Information sent to our servers

The following data is sent to our servers from the agent:

Git Integration

Scout only needs read-only access to your repository, but unfortunately, Github doesn’t currently allow this - they only offer read-write permissions through their OAuth API.

We have asked Github to offer read-only permissions, and they’ve said that the feature coming soon. In the mean time, we’re limited to the permissions structure Github offers. Our current Git security practices:

All that said, we suggest the following:

Workaround for read-only Github Access

With a few extra steps, you can grant Scout read-only access. Here’s how:

ScoutProf FAQ

Does ScoutProf work with Stackprof?

ScoutProf and StackProf are not guaranteed to operate at the same time. If you wish to use Stackprof, temporarily disable profiling in your config file (profile: false) or via environment variables (SCOUT_PROFILE=false). See the agent’s configuration options.

How is ScoutProf different than Stackprof?

Stackprof was the inspiration for ScoutProf. Although little original Stackprof code remains, we started with Stackprof’s core approach, and integrated it with our APM agent gem, changed it heavily to work with threaded applications, and implemented an easy to understand UI on our trace view.

What do sample counts mean ?

ScoutProf attempts to sample your application every millisecond, capturing a snapshot backtrace of what is running in each thread. For each successful backtrace captured, that is a sample. Later, when we process the raw backtraces, identical traces get combined and the sample count is how many of each unique backtrace were seen.

Why do sample counts vary?

Samples will be paused automatically for a few different reasons:

The specifics of exactly how often these scenarios happen depend on how and in what order your ruby code runs. Different sample counts can be expected, even for the same endpoint.

What are the ScoutProf requirements?

What’s supported during BETA?

During our BETA period, ScoutProf has a few limitations:

The ScoutProf-enabled version of scout_apm can be safely installed on all environments our agent supports: the limitations above only prevent ScoutProf from running.

Billing

Free Trial

We offer a no-risk, free 14-day trial. Delete your monitored apps before the trial concludes and you don’t pay.

Billing Date

Your first bill is 30 days after your signup date.

Subscription Style

You can choose the subscription style that makes sense for your organization. We offer two subscription styles:

Per-Server

This is the default approach. You are billed for the number of servers that are actively reporting on your billing date.

Per-Request

If you have a smaller application or have many smaller instances or Docker containers per-request billing may make more sense. Volume discounts are automatically applied as your application handles more throughput. Contact support@scoutapp.com for pricing options.

Replacing New Relic

Scout is an attractive alternative to New Relic for modern dev teams (frequent deploys, using Git, deploying to many micro instances & containers, using vendors for key infrastructure services like Amazon RDS, etc). We provide a laser-focus on getting to slow custom application code fast vs. wide breadth as debugging slow custom application code is typically the most time-intensive performance optimization work.

In many cases, Scout is able to replace New Relic as-is. However, there are cases where your app has specific needs we currently don’t provide. Don’t fret - here’s some of the more common scenarios and our suggestions for building a monitoring stack you’ll love:

Our Monitoring Stack

Curious about what a company that lives-and-breathes monitoring (us!) uses to monitor our apps? We shared our complete monitoring stack on our blog.

Talk to us about your monitoring stack

Don’t hesitate to email us if you need to talk through your monitoring stack. Monitoring is something we know and love.

Java Applications

Supported Frameworks

Scout APM has preliminary Java support for the following frameworks:

Downloading the JAR

The most recent Scout Java APM release is available for download here (direct download link, ~10MB).

wget https://www.dropbox.com/s/bzmvmq2ck8jtzhj/scout-apm.jar?dl=1 -Oscout-apm.jar

Retrieving the current version of the agent

With the following command, you retrieve the current version of the agent.

java -jar scout-apm.jar

For example:

Scout Agent version 0.3.0
See http://help.apm.scoutapp.com/#java-applications for more information

Adding the JAR to your Application

Installation depends on your app server:

Tomcat

Add the following to your setenv.sh file (and ensure setenv.sh is included from catalina.sh):

export JAVA_OPTS="$JAVA_OPTS -javaagent:/full/path/to/scout-apm/scout-apm.jar"

Karaf

Karaf also has a setenv.[sh|bat] file – see Tomcat instructions above.

If you run Karaf as a service, youll need to alter karaf-wrapper.conf and add lines like:

# Scout app monitoring
wrapper.java.additional.16=-DAPP_ENV=staging
wrapper.java.additional.17=-javaagent:d:/path/to/scout-apm.jar
# (16 and 17 are "the next free" numbers in the config file)

Embedded Containers

For environments using embedded containers, just add the following -javaagent: argument to your java invocation:

java -javaagent:/full/path/to/scout-apm/scout-apm.jar ... -jar <app-name>.jar

JBoss

JBoss Domain mode

For JBoss EAP 6.x and 7.0.x AS and above. The JVM properties for each server group are found in domain/configuration/domain.xml.

The JVM properties for each server group needs to be modified to include the -javagent argument.

<servers>
  <server name="server_01" group="group_01" auto-start="true">
    <jvm name="default" debug-enabled="false">
      <jvm-options>
        <!-- add the following option value -->
        <option value="-javaagent:/full/path/to/scout-apm/scout-apm.jar" />
      </jvm-options>
    </jvm>
  </server>
  ...

Standalone mode

For JBoss 6.x EAP and 7.0.x AS on OSX or Unix, at the bottom of bin/standalone.conf, add this

JAVA_OPTS="$JAVA_OPTS -javaagent:/full/path/to/scout-apm/scout-apm.jar"

For JBoss 6.x EAP and 7.0.x AS on Windows, at the bottom of bin/standalone.bat, add this

set JAVA_OPTS="$JAVA_OPTS -javaagent:/full/path/to/scout-apm/scout-apm.jar"

For JBoss 6.x and below on OSX or Unix, at the bottom of bin/run.conf, add this:

JAVA_OPTS="$JAVA_OPTS -javaagent:/full/path/to/scout-apm/scout-apm.jar"

For JBoss 6.x and below on Windows, at the bottom of bin/run.bat, add this

set JAVA_OPTS="$JAVA_OPTS -javaagent:/full/path/to/scout-apm/scout-apm.jar"

Configuration

The Scout Java agent looks for a scout_apm.yml configuration file in the same directory as scout-apm.jar.

/path/to/scout/scout-apm.jar
/path/to/scout/scout_apm.yml

Download the scout_apm.yml configuration file from within your account at https://apm.scoutapp.com. It includes your unique account key.

Environments

The configuration file supports multiple environments. By default, the agent reads the production environment configuration.

You can usually just leave the configuration file as-is until you need some environment-specific setting.

If you’re deploying Scout APM for the first time, we recommend starting on a staging environment. To instruct the agent to use the staging configuration, either:

Java Agent Change Log

0.5.1

0.5.0

0.4.0

0.3.0

0.2.1

0.2.0

0.1.2

0.1.1

0.1.0

0.0.5

Questions / Getting Help

Java Application monitoring is in beta. Email us with any questions about your framework and environment, or for help getting started.