Ruby gem configuration options

Configure AppSignal to be active or not for a given environment. Most commonly used in the file configuration per environment.

The environment of the app to be reported to AppSignal. This config option will be automatically detected in Rails apps. For Rails apps the RAILS_ENV variable is used to detect the environment. For apps using other frameworks or none at all, the RACK_ENV environment variable is used.

To override the automatic detecting, use the APPSIGNAL_APP_ENV environment variable.

export APPSIGNAL_APP_ENV=staging
rackup

This option will be used to load the configuration from the config files in which the AppSignal configuration is stored.

The environment variable option is commonly used on platforms where apps run in the production environment by default, such as Heroku. This setting allows an override to set the environment to staging, for example.

heroku config:set APPSIGNAL_APP_ENV=staging

Custom environments in config file {#option-appsignal_app_env-custom-environments-in-config-file}

There is no env key available in the config/appsignal.yml file. If you wish to dynamically set the environment name for an app in the config file it's possible to customize your config file to use the environment to create an environment.

# config/appsignal.yml
<%= ENV["APPSIGNAL_APP_ENV"] %>:
  active: true

If you use another environment variable than APPSIGNAL_APP_ENV make sure that matches the value is any of the auto detected environment variable names (RAILS_ENV and RACK_ENV) or the value given to Appsignal::Config.new.

The organization-level authentication key to authenticate with our Push API.

Read more about the AppSignal Push API key.

Enable debug logging, this is usually only needed on request from support. With this option enabled AppSignal will log a lot more information about decisions that are made during metrics collection and when data is sent to AppSignal.com servers.

Enabling debug logging could have a slight impact on the disk usage and IO, especially on high-traffic sites. CPU overhead is minimal with the debug option enabled.

Configure DNS servers for the AppSignal agent to use.

# config/appsignal.yml
default: &defaults
  dns_servers:
  - 8.8.8.8
  - 8.8.4.4

# In the host environment
export APPSIGNAL_DNS_SERVERS="8.8.8.8,8.8.4.4"

If you're affected by our DNS timeouts, try setting a DNS server manually using this option that doesn't use more than 4 dots in the server name.

• Acceptable values: 8.8.8.8, my.custom.local.server.
• Not acceptable values: foo, my.awesome.custom.local.dns.server.

If the DNS server cannot be reached the agent will fall back on the host's DNS configuration and output a message in the appsignal.log file: A problem occurred while setting DNS servers.

Set this option to false to disable host metrics collection.

On Heroku and Dokku host metrics are disabled by default. This is done because these systems will report inaccurate metrics from within the containers. Host metrics collection on these systems cannot be enabled. For Heroku, use the Heroku log drain instead.

The AppSignal Ruby gem stores metadata about requests and background jobs on samples by default, like request path, request method, request id, background queue, job id and job retry count. These metadata values will be shown in the tags box. If any of these metadata values contain PII or other senstive data, use this config option to filter out metadata by key.

Set the filter_metadata option to a list of metadata keys that should be filtered out. You can configure this with a list of keys in the configuration file. When filtered the metadata will not be visible in the AppSignal UI.

# config/appsignal.yml
default: &defaults
  filter_metadata:
    - path
    - request_id

List of parameter keys that should be ignored using AppSignal filtering. Their values will be replaced with [FILTERED] when transmitted to AppSignal. You can configure this with a list of keys in the configuration file.

# config/appsignal.yml
default: &defaults
  filter_parameters:
    - password
    - email
    - api_token
    - token

Read more about parameter filtering.

List of session data keys that should be ignored using AppSignal filtering. Their values will be replaced with [FILTERED] when transmitted to AppSignal. You can configure this with a list of keys in the configuration file.

# config/appsignal.yml
default: &defaults
  filter_session_data:
    - name
    - email
    - api_token
    - token

Read more about session data filtering.

List of actions that will be ignored, everything that happens including exceptions will not be transmitted to AppSignal.

Read more about ignoring actions.

Select which logger the AppSignal integration will use. Accepted values are file and stdout. See also the log_path configuration.

• file (default)
  • Write all AppSignal logs to the file system.
• stdout (default on Heroku)
  • Print AppSignal logs in the parent process' STDOUT instead of to a file. Useful with hosting solutions such as container systems and Heroku.

Set the severity level of AppSignal's internal logger. If it is configured to "info" it will log all error, warning and info messages, but not log the debug messages.

Setting it to the levels "debug" or "trace" is usually only needed on request from support. Setting the level to "debug"/"trace" could have a slight impact on the disk usage and IO, especially on high-traffic sites. CPU overhead is minimal with the debug option enabled.

Accepted values:

• error
• warning
• info
• debug
• trace

Override the location of the path (directory) where the appsignal.log file can be written to.

The request_headers config option contains a list of HTTP request headers which are read and stored by the AppSignal Ruby gem.

This request_headers config option is an allowlist, which means that it will only take headers as specified by this config option. If this config option is unset it will use the AppSignal default.

Following list is the AppSignal gem default.

# config/appsignal.yml
default: &defaults
  request_headers:
    - HTTP_ACCEPT
    - HTTP_ACCEPT_CHARSET
    - HTTP_ACCEPT_ENCODING
    - HTTP_ACCEPT_LANGUAGE
    - HTTP_CACHE_CONTROL
    - HTTP_CONNECTION
    - CONTENT_LENGTH
    - PATH_INFO
    - HTTP_RANGE
    - REQUEST_METHOD
    - REQUEST_URI
    - SERVER_NAME
    - SERVER_PORT
    - SERVER_PROTOCOL

Note that AppSignal reads the headers from your app and they may not match 1 to 1 with what is being sent in the browser/client. In Rack apps (Rails, Sinatra, etc) all custom headers are prefixed with the HTTP_ string, all header names are uppercased and dashes (-) are replaced with underscores (_).

For example, the X-Hub-Signature header can be access by your app and AppSignal with the HTTP_X_HUB_SIGNATURE name.

To configure AppSignal to not store any HTTP request headers on AppSignal transactions, configure the option with an empty array.

# config/appsignal.yml
default: &defaults
  request_headers: []

Set the app revision to report the currently running version of your app. AppSignal will create a deploy marker when this value changes, and tag all incoming data with the current revision.

When your application is deployed to Render, or when it is deployed to Heroku and the Heroku Labs: Dyno Metadata feature is enabled, the AppSignal integration will automatically detect the Git commit of the current deployment and use it as the revision.

You can overwrite the automatically detected revisions in Heroku or Render by manually setting the revision config option to a custom value.

Read more about deploy markers on the deploy markers.

AppSignal expects to be running on the same machine between different deploys. Set this key to true if the application or agent is running in a container, such as with Docker.

Newer versions of the AppSignal integration automatically detect its container environment, so no manual configuration is necessary. If you're having trouble with the automatic detection, please contact support.

This option is set to true automatically on Heroku.

Send environment metadata about the app.

For more information please read about environment metadata.

Whether to skip sending request parameters to AppSignal.

For more information please read about send_params in filtering request parameters.

Enable transaction debug mode. This enables very detailed logging of transactions and events which is useful when developing integrations or when events aren not tracked as expected. The log is only written if the general debug option is on as well.

Override the location where AppSignal for Ruby can store temporary files. Use this option if the default location is not suitable. See our how AppSignal operates page for more information about the purpose of this working directory.

If you are running multiple applications using AppSignal on the same server, use this configuration option to select different working directories for every AppSignal instance, otherwise the two instances could conflict with one another. For more information on this scenario see our running multiple applications on one host documentation.

# config/appsignal.yml
default: &defaults
  working_directory_path: "/tmp/project_1/"