Skip to content
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

Verify compliant metric API specification implementation: Measurement #3380

Closed
2 tasks done
Tracked by #3383
MrAlias opened this issue Oct 20, 2022 · 8 comments
Closed
2 tasks done
Tracked by #3383

Verify compliant metric API specification implementation: Measurement #3380

MrAlias opened this issue Oct 20, 2022 · 8 comments
Assignees
Labels
area:metrics Part of OpenTelemetry Metrics pkg:API Related to an API package

Comments

@MrAlias
Copy link
Contributor

MrAlias commented Oct 20, 2022

  • Identify all the normative requirements, recommendations, and options the specification defines as comments to this issue
  • Ensure the current metric API implementation is compliant with these normative requirements, recommendations, and options in those comments.
@MrAlias MrAlias added area:metrics Part of OpenTelemetry Metrics pkg:API Related to an API package labels Oct 20, 2022
@MrAlias MrAlias self-assigned this Jan 7, 2023
@MrAlias
Copy link
Contributor Author

MrAlias commented Jan 7, 2023

Measurement

A Measurement represents a data point reported via the metrics API to the SDK. Please refer to the Metrics Programming Model for the interaction between the API and SDK.

Measurements encapsulate:

  • A value
  • Attributes

There are no normative statements in this section. The only question that is raised is if this needs to be an explicit API or not?

The Histogram's Record operation is defined as receiving a Measurment.

  • The amount of the Measurement, which MUST be a non-negative numeric value.

Our API accepts a float64 or int64 value directly and also passes attributes. I think this is an error in the specification as if one truly reported a Measurement, which is a value and attributes, but then also provided additional attributes, it would double provide attributes.

The other place a Measurement is mentioned is in the asynchronous instrument callback design. There it uses the term Measurement to represent the value/attributes pair.

Based on this analysis, I think the Histogram's Record operation in the specification needs to be updated, and after that this section is meant as a definition of the Measurement term only (not an implemented API).

@MrAlias
Copy link
Contributor Author

MrAlias commented Jan 7, 2023

Specification PR to correct histogram parameter language: open-telemetry/opentelemetry-specification#3083

@MrAlias

This comment was marked as outdated.

@MrAlias
Copy link
Contributor Author

MrAlias commented Jan 7, 2023

Ah, it looks like this section also includes the "Multiple-instrument callbacks" as well. I'll follow up with evaluating that section next.

@MrAlias
Copy link
Contributor Author

MrAlias commented Jan 7, 2023

The Metrics API MAY support an interface allowing the use of multiple instruments from a single registered Callback.

We support this:

RegisterCallback(instruments []instrument.Asynchronous, f Callback) (Registration, error)

@MrAlias
Copy link
Contributor Author

MrAlias commented Jan 7, 2023

It is RECOMMENDED that the API authors use one of the following forms for the callback function:

  • The list (or tuple, etc.) returned by the callback function contains (Instrument, Measurement) pairs.
  • the Observable Result parameter receives an additional (Instrument, Measurement) pairs

We do not currently follow this recommendation. We should given there is no obvious reason to no as far as I can see.

The redesign of this method and its related callback is being tracked in #3519

@MrAlias
Copy link
Contributor Author

MrAlias commented Feb 2, 2023

Closed by #3519

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:metrics Part of OpenTelemetry Metrics pkg:API Related to an API package
Projects
No open projects
Status: Done
Development

No branches or pull requests

1 participant