Allow more configuration via environment variables
See original GitHub issueAs the operator of a platform on which many different Python services are deployed, it would be enormously helpful to be able to configure more sentry SDK options via environment variables, in addition to the currently-supported SENTRY_DSN
, SENTRY_ENVIRONMENT
, and SENTRY_RELEASE
options.
In particular, we would like to be able to set the value of the request_bodies
and with_locals
config options via environment variables, which we disable in production to help mitigate the risk of accidentally capturing PII, so that we can control them at the platform level rather than needing to copy/paste (and maintain) the same boilerplate code across each codebase.
We currently have the equivalent of this boilerplate code copy/pasted across the fleet of Python apps:
# SENTRY_DSN, SENTRY_ENVIRONMENT, and SENTRY_RELEASE are already set
# automatically in the process's environment at deploy time.
sentry_sdk.init(
integrations=[DjangoIntegration()],
request_bodies="never" if DEPLOY_ENV == "production" else "small",
with_locals=DEPLOY_ENV != "production",
)
It would be nice to replace that with something more like
sentry_sdk.init(
integrations=[DjangoIntegration()],
)
which is less complex and less prone to accidental misconfiguration.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:7 (5 by maintainers)
Top GitHub Comments
I think loading config from the environment is not part of the SDKs job. If we add all the config parameters to be loaded from the environment some users will still need to do something like this:
So no matter how we would implement this, it would never make everybody happy.
So imho the preferred way to do this would be something like this:
This way you can see what environment variables the config expects to be set and what default values are used in case they are not set. Makes the configuration explicit and not implicit. See also https://www.python.org/dev/peps/pep-0020/
@n1ngu I don’t think we’ll ever do an exhaustive environment config mapping, that doesn’t make sense to me. A few key options are fine to expose as env values for convenience but generalizing even function configs is overkill in my opinion.