Clarify identical instrument definition for SDK. #3585
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, the SDK states that identical instruments need to have their data aggregated together. It is implied that the definition of "identical" is defined by the metric data-model. However, the linked data-model defines identical in a way that does not include the Instrument number type. Therefore, if two instruments are "identical" in all their fields, but one if defined for double-precision floating point values and the other integer values they will need to be aggregated together. This is challenging if not impossible for strongly typed implementations. Instead, have the SDK explicitly use the definition added to the metric API defining the number type (and all other Language-level features) as identifying and therefore included in the definition of identical.
MrAlias
added
area:sdk
jmacd
approved these changes
Jul 10, 2023
jack-berg
approved these changes
Jul 11, 2023
reyang
approved these changes
Jul 12, 2023
yurishkuro
added a commit
that referenced
this pull request
Jul 18, 2023
## Changes Looking at #3585, I found a typo. While looking through the page I found a few more. Co-authored-by: Yuri Shkuro <[email protected]>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this pull request
Oct 31, 2024
## Changes Looking at open-telemetry#3585, I found a typo. While looking through the page I found a few more. Co-authored-by: Yuri Shkuro <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Currently, the SDK states that identical instruments need to have their data aggregated together. It is implied that the definition of "identical" is defined by the metric data-model. However, the linked data-model defines identical in a way that does not include the Instrument number type. Therefore, if two instruments are "identical" in all their fields, but one if defined for double-precision floating point values and the other integer values they will need to be aggregated together. This is challenging if not impossible for strongly typed implementations.
Instead, have the SDK explicitly use the definition added to the metric API defining the number type (and all other language-level features) as identifying and therefore included in the definition of identical.
This does mean that the issue of unifying instruments that differ only by the number type of the data values is left for downstream (e.g. exporter, collector) elements to handle.