-
Notifications
You must be signed in to change notification settings - Fork 621
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
Metrics instrumentation flask #1186
Metrics instrumentation flask #1186
Conversation
@TheAnshul756 is this PR ready for review? If yes, please remove the [WIP] from its name. |
Good part of this is same as in WSGI instrumentation. I am wondering if we can base all wsgi compatible frameworks on it. |
Yes I think we can implement all the wsgi based frameworks taking inspiration from WSGI Instrumentation but I don't think we can have a common function to do this job in all frameworks. Correct me if I misunderstood what you are saying. |
And when both WSGI and instrumentation are enabled they produce idetical metrics with very little changes in the time series. |
If in case we are only using specific framework instrumentation and not wsgi instrumentation then we have to have metric instrumentation implemented in the that framework, because although the frameworks take dependency on wsgi but they do not use it for metric or trace instrumentation. They have their own implementation. |
What do you mean? Why else do you think we are taking dep on wsgi instrumentation. Because we use parts of it.
Right, I am not saying they will not have any implementation on their own. But I don't see the reason each of them maintaining their own HTTP server semantic attributes, parsing the request response data from wsgi environ and filtering based on values and testing exact same thing unless you add some new tests (which is not the case with this PR). |
...tion/opentelemetry-instrumentation-flask/src/opentelemetry/instrumentation/flask/__init__.py
Show resolved
Hide resolved
...tion/opentelemetry-instrumentation-flask/src/opentelemetry/instrumentation/flask/__init__.py
Outdated
Show resolved
Hide resolved
...tion/opentelemetry-instrumentation-flask/src/opentelemetry/instrumentation/flask/__init__.py
Outdated
Show resolved
Hide resolved
@@ -290,7 +307,21 @@ def _teardown_request(exc): | |||
# a way that doesn't run `before_request`, like when it is created | |||
# with `app.test_request_context`. | |||
return | |||
start = flask.request.environ.get(_ENVIRON_STARTTIME_KEY) | |||
duration = max(round((default_timer() - start) * 1000), 0) |
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.
Shouldn't all this logic be in _start_response
?
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.
yes, that is also a possible way. But we are starting span in before_request and ending it in teardown_request so I did the same for metrics too. Also here it says that, it is discouraged, I'm also not sure what to prefer. If doing it in start_response is more acceptable then I can make the changes.
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.
Yes, please do. That comment is relevant to only tracing API and they are referring to update_name
call on span once it is started. It is discouraged because sampling decision would have already been made based on it and such edge cases.
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.
done.
...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
@@ -290,7 +307,21 @@ def _teardown_request(exc): | |||
# a way that doesn't run `before_request`, like when it is created | |||
# with `app.test_request_context`. | |||
return | |||
start = flask.request.environ.get(_ENVIRON_STARTTIME_KEY) | |||
duration = max(round((default_timer() - start) * 1000), 0) |
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.
Yes, please do. That comment is relevant to only tracing API and they are referring to update_name
call on span once it is started. It is discouraged because sampling decision would have already been made based on it and such edge cases.
...tion/opentelemetry-instrumentation-flask/src/opentelemetry/instrumentation/flask/__init__.py
Show resolved
Hide resolved
instrumentation/opentelemetry-instrumentation-flask/tests/test_programmatic.py
Outdated
Show resolved
Hide resolved
@@ -326,14 +326,30 @@ def collect_custom_response_headers_attributes(response_headers): | |||
return attributes | |||
|
|||
|
|||
def _parse_status_code(resp_status): | |||
def parse_status_code(resp_status): |
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 would still keep this and other functions private. They are not intended to be user accessible. If there is really need we can always change from private to public but not vice versa.
...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.
blocking to prevent accidental merge to make sure tests are updated
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.
Does uninstrument
stop producing the measurements? Please add some tests for instruement
/uninstrument
and other HTTP verbs.
@srikanthccv I've added test for uninstrument. What do you mean by other HTTP verbs? |
I meant something other than |
I've changed get to post in one of the test. I'm just curious why it was needed? Because I think instrumentation logic is written independent of the type of request so if it is working fine with get then it should work fine with post too? Correct me if I'm wrong. |
What I really wanted is a something like post request that sends form data and see the duration results. |
Please update the metrics support for this instrumentation here |
Or add |
…eAnshul756/opentelemetry-python-contrib into metrics-instrumentation-flask
…hub.com/shalevr/opentelemetry-python-contrib into feature/Metrics-instrumentation-urllib3 * 'feature/Metrics-instrumentation-urllib3' of https://github.com/shalevr/opentelemetry-python-contrib: Metric instrumentation asgi (open-telemetry#1197) Metrics instrumentation flask (open-telemetry#1186) Adding sqlalchemy native tags in sqlalchemy commenter (open-telemetry#1206)
* main: Codespell ci (open-telemetry#1237) aiohttp-client: Fix producing additional spans with each newly created ClientSession (open-telemetry#1246) Remove support for 3.6 (open-telemetry#853) Added the Licence and Manifest file Restore metrics in django (open-telemetry#1208) fix typo in example codes (open-telemetry#1240) boto3sqs: Make propagation compatible with other instrumentations and add 'messaging.url' span attribute (open-telemetry#1234) Release 1.12.0-0.33b0 (open-telemetry#1223) Fix Flask instrumentation doc link (open-telemetry#1216) Feature/metrics instrumentation urllib3 (open-telemetry#1198) Metric instrumentation asgi (open-telemetry#1197) Metrics instrumentation flask (open-telemetry#1186) Adding sqlalchemy native tags in sqlalchemy commenter (open-telemetry#1206) ci: fix docs workflow failure (open-telemetry#1211) Add psycopg2 native tags to sqlcommenter (open-telemetry#1203) SQLCommenter semicolon bug fix (open-telemetry#1200) Sync with sdk setup from setUpClass to setUp (open-telemetry#1193) # Conflicts: # CHANGELOG.md # instrumentation/opentelemetry-instrumentation-tornado/src/opentelemetry/instrumentation/tornado/__init__.py # instrumentation/opentelemetry-instrumentation-tornado/src/opentelemetry/instrumentation/tornado/client.py
Description
Fixes #1155
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
tox -e test-instrumentation-flask
Does This PR Require a Core Repo Change?
Checklist:
See contributing.md for styleguide, changelog guidelines, and more.