Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for generic OTEL_PYTHON_EXCLUDED_URLS variable #789

Closed
adamantike opened this issue Nov 2, 2021 · 1 comment · Fixed by #790
Closed

Add support for generic OTEL_PYTHON_EXCLUDED_URLS variable #789

adamantike opened this issue Nov 2, 2021 · 1 comment · Fixed by #790

Comments

@adamantike
Copy link
Contributor

Is your feature request related to a problem?
Right now, to exclude URLs from being traced using environment variables, the OTEL_PYTHON_{instrumentation}_EXCLUDED_URLS naming convention must be used.
However, considering that the inner workings of the excluded URLs are independent of the running integration, and actually related to the ExcludedList implementation, having support for a generic OTEL_PYTHON_EXCLUDED_URLS would simplify deployments of different stacks, where DevOps are in charge of creating reusable modules that centralize OpenTelemetry configuration (e.g. OTEL_PROPAGATORS, OTEL_PYTHON_ID_GENERATOR).

Describe the solution you'd like
Having this library read the OTEL_PYTHON_EXCLUDED_URLS environment variable, as a fallback when no value is found at OTEL_PYTHON_{implementation}_EXCLUDED_URLS.

Describe alternatives you've considered
As it is today, having reusable modules for Infrastructure-as-Code requires to either know which application is being deployed (Django, FastAPI, Tornado...), to set the related environment variable, or set all of them even if not required, to simplify the logic and avoid developers needing to be explicit about the framework being used.

For the solution, an alternative approach would be for OTEL_PYTHON_EXCLUDED_URLS to extend what's provided by OTEL_PYTHON_{implementation}_EXCLUDED_URLS. However, that could be a separate discussion.

@owais
Copy link
Contributor

owais commented Nov 2, 2021

Sounds good to me. We should create an issue per instrumentation to track this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants