Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Adding metric collection as part of instrumentations - Requests #1116
Adding metric collection as part of instrumentations - Requests #1116
Changes from 14 commits
e7f9183
d7f771e
c17732b
b85c02a
66890b5
250422e
d36979c
daef875
94bedde
adaeee3
8378400
6db3175
3157ef8
3b65383
43ccc7a
ea883d3
58ace95
b93342c
ff4c491
195d876
06b7fde
d24043a
b21da84
7ec6590
6076bab
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 it possible to infer http.scheme as well here using 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.
Yes. However, if
url
is available, it takes priority since all components of the URI can be derived from it. See https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/semantic_conventions/http-metrics.md#parameterized-labelsThere 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.
What do you think about only exposing the
meter
property and removing this code, so users would have to do:Then you can remove the
opentelemetry-sdk
dependency for the instrumentation. This might be overly pedantic, but depending on theopentelemetry-sdk
prevents people from using a third-party SDK (if one ever existed).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 actually thinking about this approach originally, just expose the
meter
so users can decide what they want to do with it. I'm okay with t removing the automatically started pipeline. However, this feature requires the dependency onopentelemetry-sdk
regardless, because of line 63 inmetric.py
inopentelemetry-instrumentation
. To enable this, the sdk implementation ofValueRecorder
must be used, so we MUST have a dependency on it. I think the message is: if you want to autocollect these metrics, this will be a feature offered by the default sdk and so you have to install it. I also don't know if the api and sdk separation of metrics makes sense today. Will we ever even have a different implementation of the metrics sdk? It's not really the same as the tracer, in which we would.If there is a big push to not take a dependency on the sdk, we would probably have to change our metrics api implementation and create an explicit
create_value_recorder
method for themeter
s. I'm actually okay with this, but might want to leave this for another pr. 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.
Ya I agree it would be easy to work around that use of
ValueRecorder
later if we decide the instrumentation shouldn't take dependency on the SDK (it would be breaking change to the Instrumentor constructor though?). Could you explain why the api/sdk separation isn't the same with metrics as it is with tracer (I think I'm missing some background info)?Would be great to get other Python SIG folks' thoughts on this too
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 feel like we don't expect people to implement their own sdk to record + export metrics. It's as if we introduced the api + sdk separation simply to match what trace is doing.
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 discussion makes me wonder if the behaviour exposed in the ValueRecorder by the SDK should just be in the API then, instead of having an interface that is not usable with the SDK. If this isn't already being discussed in the metrics SIG, it should, I would suspect other SIGs are running into similar issues.
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.
Java implementation and Go implementation both have constructors for each metric instrument. So depending on whether they are using the sdk
MeterProvider
or not, it returns different implementations of the instrument, so they have an interface that is useable by the SDK. We should probably do something similar.