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
HttpSemanticConventions - update AspNetCore histogram #4766
HttpSemanticConventions - update AspNetCore histogram #4766
Changes from 4 commits
975accc
b8d69ac
72b429e
4f016cf
99d54c1
56676a9
598ca2f
d4776ba
b2c5b82
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.
Java gates this change with the
OTEL_SEMCONV_STABILITY_OPT_IN
setting. Maybe we should too since this is potentially disruptive to end users and backends.Unfortunately, it's not explicitly stated that this change should be gated, but maybe it should be... @trask what do you think?
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.
within the scope of HTTP semconv, I think(?) this is implied by the spec, since unit
seconds
is part of the frozen http semconv forhttp.server.request.duration
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 was my original interpretation... but I also can understand how someone might have a different interpretation since the words from the warning text are very attribute-centric.
I'd be happy to take a stab at some clarifying verbiage to the text if folks would find that helpful.
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.
ah, thx, I see the confusion now
that would be great
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 should be done by the application user, not the instrumentation library. Instrumentation Library can set Hint (once that feature is available), but it should not try to Configure View. View is a SDK concept, and instrumentation library should not have sdk dependency at all. (its an issue that this library has an undesired dependency on sdk, thats tracked separately)...
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.
Experimental spec for Hint API ("instrument advice") is here:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#instrument-advice
Seems that Trask is ready to move it to Stable:
open-telemetry/opentelemetry-specification#3391
I had a brief chat with Utkarsh about this.
Seems the Hint API will be a blocker for this 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.
Hint API require DiagnosticSource changes, so not coming this year.
But i don't know if Hint API support is required before making this change. As users always have View API to adjust bounds.
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.
IMO, that seems like a bad user experience.
If the Instrumentation library ships with the wrong buckets and users need to manually adjust.
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.
mm. If that is the case, then the stable release of instrumentation must be tied with next .NET release (Nov 2024). dotnet/runtime#63650 (comment)
Or some options must be added for instrumentation library to use ms instead of s. I recommend to create a dedicated issue to discuss this.
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.
@cijothomas On thinking a bit more about this, I think it should be okay for the instrumentation library to use
View
until the Hint API is offered from DiagnosticSource. When the Hint API is available, the instrumentation library could get rid ofView
and switch to using the Hint API.As of today, anyone using AspNetCoreInstrumentation library is going to take a dependency on the SDK anyway.
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 can include a TODO here to call out that this needs to be changed to Hint API when available.
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 open a dedicated issue to discuss and record this decision. It's a pretty fundamental principle that instrumentations should only depend on the API and not on the SDK, and so you'll want to document the rationale clearly in this case and make sure your entire community is onboard and understands the ramifications.
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.
It can still cause other issues as Views are additive. If user adds another view matching the same metric, to drop an unwanted attribute, it'll result in 2 metrics stream.
Its a bug that the instrumentation has a SDK dependency. It is fixable (once we move the things the instrumentation need from SDK to API itself.). Its even worse if the instrumentation leverages the SDK dependency to define behavior, reserved for application owner to define.
There are other instrumentations where this trick/hack of using views from SDK cannot be used - like asp.net framework.
At the cost of exposing yet another public API, an option like
RecordDurationInMillisecond
could work, and is probably more desirable than misusing SDK dependency.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.
Add a check for both Meter name and Instrument name.