-
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
Add support for HTTPX instrumentation #461
Add support for HTTPX instrumentation #461
Conversation
|
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. Instrumentation LGTM. Left a few minor comments.
...tion/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/__init__.py
Outdated
Show resolved
Hide resolved
...tion/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/__init__.py
Outdated
Show resolved
Hide resolved
...tion/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/__init__.py
Outdated
Show resolved
Hide resolved
...tion/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/__init__.py
Show resolved
Hide resolved
The docs check fails because of a missing requirement. It's added in #463, so I will rebase and update the versions once that is merged. |
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. Looks really good. Left a couple of questions.
...tion/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/__init__.py
Outdated
Show resolved
Hide resolved
@owais have your comments been addressed? |
I have changes for 0.18.x of |
@jomasti Anything I can help with here? Very interested on this instrumentation. |
This builds off of the initial idea in [this issue][1] of using the transport API in `httpx`. This allows for using [custom transports][2]. One issue with this current implementation is that there are few more [changes coming][3] in 0.18.0 that this will probably want to use. So maybe it will make sense to finalize this on that version before releasing it. Want to get some eyes on this sooner. Resolves #263 [1]: encode/httpx#1264 (comment) [2]: https://www.python-httpx.org/advanced/#custom-transports [3]: encode/httpx#1522
This is to avoid calling `get_tracer` every time.
Replaces the span and name callbacks
Simplifies the usage of request/response hooks for consumers with expected objects
Allows for instrumenting and uninstrumenting existing client instances
Not sure how that happened.
Back to only providing the raw arguments and return values instead of using httpx Request and Response objects to avoid any additional overhead or unexpected side effects.
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.
LGTM. Thanks!
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.
Looks great. Just a suggestion to use namedtuple for hook args.
...tion/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/__init__.py
Outdated
Show resolved
Hide resolved
Easier usage in hooks
...ation/opentelemetry-instrumentation-httpx/src/opentelemetry/instrumentation/httpx/version.py
Outdated
Show resolved
Hide resolved
opentelemetry-instrumentation/src/opentelemetry/instrumentation/bootstrap_gen.py
Outdated
Show resolved
Hide resolved
Have you gotten a chance to look at the instrumentation guidelines and expectations? |
I have. Is there something specific you are wanting to highlight in those? |
extensions=extensions, | ||
) | ||
|
||
span_attributes = _prepare_attributes(method, url) |
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.
Attributes should not be recorded if is_recording()
is false.
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.
The attributes are not recorded in this function call, but later in _apply_status_code
, which checks is_recording()
. Do you suggest changing this to make it more clear?
It would be great if you could create issues for the features that are not included yet in this PR for this instrumentation (such as |
@lzchen Isn't |
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.
Just a minor comment in the setup file. @lzchen would it be ok to create a separate issue to add exclude_url functionality since the same functionality will be needed for requests as well.
Programming Language :: Python :: 3 | ||
Programming Language :: Python :: 3.6 | ||
Programming Language :: Python :: 3.7 | ||
Programming Language :: Python :: 3.8 |
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.
Should include Python 3.9
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 will add it, but it looks like this is missing from almost all the other packages.
Yes that's fine. @jomasti No need to add these features in this PR. It would be great if you could create issues for them to track :) |
@lzchen I can make an issue for the exclude urls feature. Looking at the functionality provided by the url filter in the example, it seems that the request hook functionality here should provide a way to accomplish the same thing. Or am I overlooking something? |
Description
This builds off of the initial idea in this issue of using the
transport API in
httpx
. This allows for using custom transports.This allows for manually creating transports to use with individual
clients and for instrumenting all created clients.
One issue with this current implementation is that there are few more
changes coming in 0.18.0 that this will probably want to use. So
maybe it will make sense to finalize this on that version before
releasing it. Want to get some eyes on this sooner.
Fixes #263
Type of change
How Has This Been Tested?
Added unit tests for the transports used manually and for an instrumentor class
Does This PR Require a Core Repo Change?
Checklist:
See contributing.md for styleguide, changelog guidelines, and more.