Clone this wiki locally
Note: Wiki covers configuration for version 2.x. For version 1.x configuration, please visit Configuration Version 1.x.
There are two primary ways to configure
librato-rails. You can either use a yaml-based config file, environment variables, or a combination of the two.
When using a config file you configure each environment separately. Environment variables differ in that they will be used by all environments when present.
To use a config file, create a file named
librato.yml in the
config directory of your rails project. Here's a sample config file:
production: user: 'firstname.lastname@example.org' token: 'api key' staging: user: 'email@example.com' token: 'api key' prefix: 'staging'
The following options can be set per environment in config files:
- user - the email address of your Librato Metrics account
- token - the api key of your Librato Metrics account
tags - the tags metrics will be reported from. (default:
host). If you are overriding this you likely want to set it to a different value per host or host group.
prefix - an optional prefix which will be attached to all metric names reported by librato-rails. For example, if the prefix is set to
rails.request.totalwill be reported as
- suites - specify which metrics librato-rails will report. See more in Metric Suites
- proxy - HTTP proxy to use when connecting to the Librato API.
log_level - useful for debugging, default level is
info, available levels are
[off, error, warn, info, debug, trace].
- flush_interval - how often aggregated metrics will be sent, in seconds (default: 60). Useful in local debugging to force more frequent flushes. Don't use this in production - it will not give you more frequent data on Metrics, but it may affect performance of your application.
LIBRATO_USER- the email address of your Librato Metrics account
LIBRATO_TOKEN- the api key of your Librato Metrics account
LIBRATO_TAGS- the default tags metrics will be reported from. Format is comma-separated key=value pairs, e.g. region=us-east,az=b. If not set,
hostof the executing machine is detected and set as default tags
LIBRATO_PREFIX- optional prefix, see
LIBRATO_SUITES- specify which metrics librato-rails will report. See more in Metric Suites
LIBRATO_PROXY- HTTP proxy to use when connecting to the Librato API (can also use the https_proxy or http_proxy environment variable commonly supported by Linux command line utilities).
LIBRATO_LOG_LEVEL- useful for debugging, see above
LIBRATO_AUTORUN- if set to
'0', forces librato-rails not to start, see more below
Note that most environment variables will be ignored if a
librato.yml file is present. For convenience
LIBRATO_AUTORUN will override values specified in a
Heroku users: If you are using the Librato Heroku add-on, the
LIBRATO_TOKEN will be automatically set already in your environment.
LIBRATO_AUTORUN was introduced in v0.10 and controls two related behaviors.
If set to
0 it will prevent the
librato-rails reporter from starting. Instrumentation classes/methods will still be available for convenience, but nothing will ever be sent to Librato.
If set to
1 it will force the reporter to start immediately, instead of waiting for the process to receive a request. This can be useful with some kinds of background workers which won't report otherwise. However, be sure not to use this setting with normal rails web processes! Reporting will be broken because it is forced to start before the web-serving environment is fully loaded.
See Monitoring Background Workers for more information about using
LIBRATO_AUTORUN with workers.
Combining config files and environment variables
If you want to use a
librato.yml file but still have the versatility of environment variables for setting some features per-environment, you can include environment variables in your config file using erb. For example:
production: user: <%= ENV['LIBRATO_USER'] %> token: <%= ENV['LIBRATO_TOKEN'] %> development: user: <%= ENV['LIBRATO_USER'] || 'firstname.lastname@example.org' %> token: <%= ENV['LIBRATO_TOKEN'] || 'mydevtoken' %>
Note that you can use any environment variables you wish in this fashion, you are not locked into the standard variables that
librato-rails would look for if it was inspecting the environment for configuration.