Configuration
This document describes configuration available to the Sentry server itself.
During a new install, Sentry prompts first for a walkthrough of the Installation Wizard. This wizard will help you get a few essential configuration options taken care of before beginning. Once done, you will be left with two files:
config.yml
- The YAML configuration was introduced in Sentry 8 and will allow you to configure various core attributes. Over time this will be expanded.
sentry.conf.py
- The Python file will be loaded once all other configuration is referenced, and allows you to configure various server settings as well as more complex tuning.
Many settings available in config.yml
will also be able to be configured in the Sentry UI. Declaring them in the file will generally override the dynamically configured value and prevent it from being changed in the UI. These same settings can also be configured via the sentry config
CLI helper.
SENTRY_ENVIRONMENT
Declared in System Environment
The environment name for this installation. This will also control defaults for things like DEBUG
.
SENTRY_ENVIRONMENT=production sentry ...
system.admin-email
Declared in config.yaml
The technical contact address for this installation. This will be reported to upstream to the Sentry team (as part of the Beacon), and will be the point of contact for critical updates and security notifications.
system.admin-email: "admin@example.com"
system.url-prefix
Declared in config.yaml
The URL prefix in which Sentry is accessible. This will be used both for referencing URLs in the UI, as well as in outbound notifications. This only works for scheme, hostname and port. Sentry needs to be at the root of its own (sub)domain or IP address, and you cannot include path information (not even a trailing slash) in the system.url-prefix
option.
system.url-prefix: "https://sentry.example.com"
system.secret-key
Declared in config.yaml
A secret key used for session signing. If this becomes compromised it’s important to regenerate it as otherwise its much easier to hijack user sessions.
system.secret-key: "a-really-long-secret-value"
To generate a new value, we’ve provided a helper:
sentry config generate-secret-key
Sentry logs to two major places — stdout
, and its internal project in Sentry. By default, all levels of logs are printed to the console, but only error
level logs are captured and sent to Sentry. To disable logging to the internal project (in other words, to prevent the server's built-in SDK instance from sending events to Sentry), add a logger whose only handler is 'console'
and which has propagate
set to False
.
You will find the CLI flag and the environment variables related to logging below. They override the root logger and anything in LOGGING.overridable
. Be very careful with these in a production system, because the Celery logger can be extremely verbose when set to INFO or DEBUG.
-l/--loglevel
Declared on the command line
Sentry can override logger levels by providing the CLI with the -l/--loglevel
flag.
The value of this can be one of the standard Python logging level strings.
sentry --loglevel=WARNING
SENTRY_LOG_LEVEL
Declared in System Environment
Sentry can override logger levels with the SENTRY_LOG_LEVEL
environment variable.
The value of this can be one of the standard Python logging level strings.
SENTRY_LOG_LEVEL=WARNING sentry ...
LOGGING
Declared in sentry.conf.py
You can modify or override the full logging configuration with this setting. Be careful not to remove or override important defaults. You can check the default configuration for reference.
LOGGING['default_level'] = 'WARNING'
If logging in a particular module is not showing up when you expect it to, you should check the log level for that module in src/sentry/conf/server.py
in the LOGGING
variable.
redis.clusters
Declared in config.yaml
Describes the Redis clusters available to the Sentry server. These clusters may then be referenced by name by other internal services such as the cache, digests, and TSDB backends, among others.
For example,
redis.clusters:
default: # cluster name
hosts: # connection options, passed to `rb.Cluster`
0:
host: redis-1.example.com
port: 6379
1:
host: redis-2.example.com
port: 6379
other:
hosts:
0:
host: redis-3.example.com
port: 6379
The following keys control the authentication support.
auth.allow-registration
Declared in config.yaml
Should Sentry allow users to create new accounts?
Defaults to False
.
This setting only controls public registration. Users can still register new accounts via Single Sign-On and membership invites.
auth.allow-registration: true
Note: This setting is often configured via the UI.
SENTRY_PUBLIC
Declared in sentry.conf.py
Should Sentry make all data publicly accessible? This should only be used if you’re installing Sentry behind your company’s firewall.
Users will still need to have an account to view any data.
Defaults to False
.
SENTRY_PUBLIC = True
SENTRY_ALLOW_ORIGIN
Declared in sentry.conf.py
Note: This setting has changed, and no longer applies to /api/store/
requests.
If provided, Sentry will set the Access-Control-Allow-Origin header on all web API responses.
You can read more about these headers in the Mozilla developer docs.
Defaults to *
(allow API access from any domain)
SENTRY_ALLOW_ORIGIN = "http://foo.example"
The following settings are available for the built-in webserver:
SENTRY_WEB_HOST
Declared in sentry.conf.py
The hostname which the webserver should bind to.
Defaults to localhost
.
SENTRY_WEB_HOST = '0.0.0.0' # bind to all addresses
SENTRY_WEB_PORT
Declared in sentry.conf.py
The port which the webserver should listen on.
Defaults to 9000
.
SENTRY_WEB_PORT = 9000
SENTRY_WEB_OPTIONS
Declared in sentry.conf.py
A dictionary of additional configuration options to pass to uwsgi.
Defaults to {}
.
SENTRY_WEB_OPTIONS = {
'workers': 10,
'buffer-size': 32768,
}
Additionally, if you’re using SSL, you’ll want to configure the following settings in sentry.conf.py
:
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
github-app.id
Declared in config.yaml
Your GitHub App ID.
github-app.name
Declared in config.yaml
The name of your GitHub App.
github-app.webhook-secret
Declared in config.yaml
The secret used to verify GitHub App Webhook event.
github-app.private-key
Declared in config.yaml
Your app's private key, best to use multiline:
github-app.private-key: |
-----BEGIN RSA PRIVATE KEY-----
privatekeyprivatekeyprivatekeyprivatekey
privatekeyprivatekeyprivatekeyprivatekey
privatekeyprivatekeyprivatekeyprivatekey
privatekeyprivatekeyprivatekeyprivatekey
privatekeyprivatekeyprivatekeyprivatekey
-----END RSA PRIVATE KEY-----
github-app.client-id
Declared in config.yaml
Your GitHub App's Client ID.
github-app.client-secret
Declared in config.yaml
Your GitHub App's Client Secret.
First create an Azure DevOps App
vsts.client-id
Declared in config.yaml
Your Azure DevOps application App ID
vsts.client-secret
Declared in config.yaml
Your Azure DevOps application App Secret
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").