-
Notifications
You must be signed in to change notification settings - Fork 595
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 exclude lists for Django #670
Conversation
ext/opentelemetry-ext-django/src/opentelemetry/ext/django/middleware.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functionally looks good! see comments for a performance improvement I think is quite important.
ext/opentelemetry-ext-django/src/opentelemetry/ext/django/middleware.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-django/src/opentelemetry/ext/django/middleware.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can still cause an excluded path to reject an URL regardless of its host, but if this is the functionality you want to implement, it is fine 👍
Just requesting changes for a couple of print
s. If they are necessary let me know and I'll approve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the changelog
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes! And refactoring looks good. There's a slight issue with the global cache that I think should be addressed now.
@@ -2,6 +2,8 @@ | |||
|
|||
## Unreleased | |||
|
|||
- Add exclude lists |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to add a more descriptive changelog. Can you add a line to describe what the purpose is, or how it should be used?
return paths | ||
|
||
|
||
_excluded_hosts = get_excluded_hosts() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe this will work as intended, or at least not consistently.
If the instrumentation is imported before configuration is set, then these values will be None, and as a result will not exclude any paths nor hosts. This is uncommon for environment variables where things are set before the process starts, but if we start including ways to configure the Configuration object (e.g. set once), this will result in these global variables resolving before anyone can set the configuration.
Here's a short example:
from opentelemetry.ext.flask import FlaskInstrumentor # start of the file, so it loads, and sets the _excluded_hosts global
from opentelemetry import Configuration
Configuration().set(flask_excluded_path="/foo") # this will not honored, as the global was already set.
I think a safer approach would be lazy evaluation: have a getter than populates the value when it's called for the first time. Generally you can feel confident it won't be invoked until the first time it has to match the route, or after instrumentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the use case. Configurations aren't able to be set, they are populated in the first instance that they are used by reading from the environment variables. If the instrumentation is imported, Configuration will just be set the moment that it is called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, there is no way to set Configuration pro grammatically, although we might allow this in the future (set it once, and then it becomes immutable). A lazy load getter seems to makes sense as well in this case. I believe we should have this in a separate PR, since that is more about changing the API of Configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ocelotl might have to weigh in, but I worry not doing this change now will result in a bug later on. I'll at least file an issue here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great, thanks!
Similar to exclude listing for flask, implement for Django.
Also fixed some tests in
flask
that weren't being executed.