-
Notifications
You must be signed in to change notification settings - Fork 626
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
Capture custom request/response headers for wsgi and change in passing response_headers in django, pyramid #925
Capture custom request/response headers for wsgi and change in passing response_headers in django, pyramid #925
Conversation
3adf3de
to
e864f36
Compare
447533e
to
f2b2288
Compare
...tation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
Outdated
Show resolved
Hide resolved
...tation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
Outdated
Show resolved
Hide resolved
util/opentelemetry-util-http/src/opentelemetry/util/http/__init__.py
Outdated
Show resolved
Hide resolved
|
||
return result | ||
|
||
|
||
def capture_custom_request_headers(environ, attributes): |
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.
Any specific reason to pass the attribute dict as a argument and modifying it with new headers rather than returning the headers to calling function?
I think it will be better from readability perspective to update the result dict in a single function rather than passing to called function and update there
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.
Agree. It is not clear what the function does without reading the function body.
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.
Added suggested changes to improve readability. Please have a look.
attributes[key] = [header_values] | ||
|
||
|
||
def capture_custom_response_headers(response_headers, span): |
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.
same comment as I have given in capture_custom_request_headers()
from urllib.parse import urlparse, urlunparse | ||
|
||
OTEL_CAPTURE_REQUEST_HEADERS = "OTEL_CAPTURE_REQUEST_HEADERS" |
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.
Do we want to further split this to client/server like Java does?
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 is good to split as this will make the feature consistent between different sdks. Also, will keep the env vars same as java sdk.
Not sure but, when I first read the spec it felt like its only talking about the server side. Please share your thoughts :)
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.
Seems like we are going with the general approach for being consistent with other language sdks like here so it would make sense to follow suit.
@@ -161,7 +161,7 @@ def trace_tween(request): | |||
otel_wsgi.add_response_attributes( | |||
span, | |||
response_or_exception.status, | |||
response_or_exception.headers, | |||
response_or_exception.headerlist, |
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.
Is this safe for all supported version of django?
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 guess you are referring to response.items()
in .../instrumentation/django/middleware.py
Yes, I have tested it with lowest supported version of django by running the unit tests (as docs for django dont' say anything about this property below 4.0) and also done same for pyramid.
Do we run tests for different versions of a framework in the build jobs?
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 was planning to add tests for all wsgi based frameworks in different PR.
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 was referring to replacing headers
with headerlist
. Is headerlist
attribute available on all supported versions of django?
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.
available on all supported versions of django?
I think there is some confusion, the change header
to headerlist
is for pyramid :)
Is headerlist attribute available on all supported versions
Yes, I checked pyramid docs, headerlist
attribute is available in all versions of pyramid we support (>=1.7).
|
||
return result | ||
|
||
|
||
def capture_custom_request_headers(environ, attributes): |
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.
Agree. It is not clear what the function does without reading the function body.
- Django: Passing response header instead of response object
Fixing lint errors
Co-authored-by: Srikanth Chekuri <[email protected]>
1) Passing mulitple header values as single string in a list 2) Changing Env varibale name
Co-authored-by: Leighton Chen <[email protected]>
8011ad5
to
aedc4e2
Compare
Can someone run combine benchmarks from previous build again? |
@sanketmehta28 |
@lzchen:yes I have checked it. They are addressed. I will approve this PR. |
1 similar comment
@lzchen:yes I have checked it. They are addressed. I will approve this PR. |
I forgot to add the condition to check if the span is a |
...tation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
Outdated
Show resolved
Hide resolved
...tation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.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.
mostly LGTM; few questions.
"http.response.header.content_type": ( | ||
"text/plain; charset=utf-8", | ||
), | ||
"http.response.header.content_length": ("100",), |
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.
Hmm, why is everything a sequence? it doesn't make sense that content_length is list, right?
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.
This is part of the spec actually.
The attribute value MUST consist of either multiple header values as an array of strings or a single-item array containing a possibly comma-concatenated string, depending on the way the HTTP library provides access to headers.
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.
but that is for the multiple header values?
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 its for single values also. There is an example in the spec.
http.request.header.content_type=["application/json"]
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.
That's strange but not a blocker for me.
Description
User can configure environment variable
OTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_REQUEST
andOTEL_INSTRUMENTATION_HTTP_CAPTURE_HEADERS_SERVER_RESPONSE
to capture request/response headers respectively.django
Instrumentation to pass response headers instead of response object.pyramid
instrumentation to pass response headers as list.Fixes #918
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Added unit tests for the changes. Also, tested captured headers manually with wsgi based framework by observing the output on jaeger backend.
Does This PR Require a Core Repo Change?
Checklist:
See contributing.md for styleguide, changelog guidelines, and more.