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

Replace Temporality with Kind; Type with ValueType #168

Closed
wants to merge 40 commits into from

Conversation

jmacd
Copy link
Contributor

@jmacd jmacd commented Jul 15, 2020

This is a partial re-do of #162 with only the Kind and ValueType changes and more extensive comments.

Type renamed ValueType
Temporality values (CUMULATIVE, DELTA, INSTANTANEOUS) move into Kind
Structure values (ADDING_MONOTONIC, ADDING, GROUPING) included in Kind
Continuity values (SNAPSHOT, CONTINUOUS) included in Kind
Monotonic becomes a Structure

Part of #125
Resolves #124
Resolves #78

@jmacd jmacd requested a review from a team July 15, 2020 09:02
opentelemetry/proto/metrics/v1/gen.go Outdated Show resolved Hide resolved
opentelemetry/proto/metrics/v1/gen.go Outdated Show resolved Hide resolved
@jmacd
Copy link
Contributor Author

jmacd commented Jul 15, 2020

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (minor nits) except the async bit which unfortunately I fail to understand the implication on the consumer.

opentelemetry/proto/metrics/v1/gen.go Outdated Show resolved Hide resolved
opentelemetry/proto/metrics/v1/gen.go Show resolved Hide resolved
opentelemetry/proto/metrics/v1/metrics.proto Outdated Show resolved Hide resolved
opentelemetry/proto/metrics/v1/metrics.proto Outdated Show resolved Hide resolved
opentelemetry/proto/metrics/v1/metrics.proto Outdated Show resolved Hide resolved
@bogdandrutu
Copy link
Member

@jmacd you had a go mod/sum in the original PR consider to send a quick PR to add them to the repo (independent of any proto changes)

@jmacd
Copy link
Contributor Author

jmacd commented Jul 20, 2020

@lubingfeng

I sure hope we have resolved the issues and can get these changes merged in 2 weeks. @open-telemetry/specs-metrics-approvers Let's Really Do This.

@lubingfeng
Copy link

lubingfeng commented Jul 20, 2020

I sure hope we have resolved the issues and can get these changes merged in 2 weeks. @open-telemetry/specs-metrics-approvers Let's Really Do This.

This is great. I plan to attend this Thursday's SIG meeting for metrics and would be good to hear latest progress / status on those four pull requests:
#168
#170
#159
#171

SUMMARY = 6;
// Summary implies that the value is found in
// Metric.summary_data_points[].summary.
SUMMARY = 4;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking ahead to the exemplars changes; in #162 we had SUMMARY_INT64 and SUMMARY_DOUBLE which lets us determine the data type of exemplars (int or double). But if we only specify double types for summary, does it make sense to have a SUMMARY_INT64 and SUMMARY_DOUBLE type for only exemplars or should there be a different enum for raw measurement type? Same thing for histogram

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was on the fence about creating _INT64 and _DOUBLE variations of Histogram and Summary data points. I wouldn't object, but I fear this is more detail than most people want. I draw a distinction between single-value data points (SCALAR, RAW) and multi-value data points (HISTOGRAM, SUMMARY). I think it's more OK to support only floats for multi-value data points, basically, and really not OK to do that for scalars and raw values.

I asked around whether this was a real problem at Google, and in cases it was. If you count your network traffic in bits per second, your router is likely to overflow a 2^50 counter but not a 2^64 counter.

//
// 1. CUMULATIVE GROUPING kinds typically use Histogram data points
// 2. CUMULATIVE is rarely used with Summary data points
enum Kind {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spent time during the weekend trying this new proposal, and found a lot of things that don't make a lot of sense.

See more details here and a proposed different approach of thinking about the data model:
https://docs.google.com/document/d/1UBpke_e_HWl7UV3piNIMAZYw8eNjfGjucdwwsEOqUI4/edit#

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't hesitate to comment in the doc or here. Will try to answer all the comments :)

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more comments, I read this proposal now at least 5 times and I still don't understand the subtle things and edge cases which makes me feel that this is too complicated and will not be able to use it as a generic protocol.

// may be interpreted differently depending on Structure. For
// example, a Histogram DataPoint may be computed for a Counter
// (ADDING) instrument or a ValueRecorder (GROUPING) instrument, and
// the Sum and Count of the resulting aggregation may be interpreted
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how Count relates to "Structure", I see "Count" being related with Temporality not structure.

Comment on lines 200 to 202
// by equal Resource and TimeUnixNano values. SNAPSHOT metrics
// MUST NOT have more than one data point per TimeUnixNano,
// Resource, and LabelSet. If the interpreter of this data finds
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SNAPSHOT metrics MUST NOT have more than one data point per TimeUnixNano, Resource, and LabelSet.

This is true for every metric correct?

@bogdandrutu bogdandrutu reopened this Jul 23, 2020
@bogdandrutu bogdandrutu requested a review from MrAlias July 23, 2020 23:27
bogdandrutu added a commit to bogdandrutu/opentelemetry-proto that referenced this pull request Jul 29, 2020
… the aggregation and temporality.

This PR takes a more descriptive approach where the Aggregation (the last applied aggregation if any) is clearly defined and Temporality is available only where it makes sense. This can help clearly identify what are the possible values and properties for different types of Aggregations.

There are some things that can be considered (TODOs left in the code):

* open-telemetry/opentelemetry-specification#725
* Histogram/Summary sum - monotonicity?
* Previous aggregation measurements: raw measurements or "derived" measurements (results of another aggregation).
* Support for RawMeasurements (recorded via the Sync Instruments)

IMPORTANT:
* This PR is not equivalent with open-telemetry#168 or open-telemetry#181, this is inspired by these PRs but makes some changes that are not compatible with that PR.
* This PR is an incremental update, without any significant semantic changes (except adding the notion of GAUGE), from the current state,
  more changes will be added in the future to resolve the TODOs.

Signed-off-by: Bogdan Drutu <[email protected]>
bogdandrutu added a commit to bogdandrutu/opentelemetry-proto that referenced this pull request Jul 29, 2020
… the aggregation and temporality.

This PR takes a more descriptive approach where the Aggregation (the last applied aggregation if any) is clearly defined and Temporality is available only where it makes sense. This can help clearly identify what are the possible values and properties for different types of Aggregations.

There are some things that can be considered (TODOs left in the code):

* open-telemetry/opentelemetry-specification#725
* Histogram/Summary sum - monotonicity?
* Previous aggregation measurements: raw measurements or "derived" measurements (results of another aggregation).
* Support for RawMeasurements (recorded via the Sync Instruments)
* Decide if support for INSTANTANEOUS temporality is still needed.

IMPORTANT:
* This PR is not equivalent with open-telemetry#168 or open-telemetry#181, this is inspired by these PRs but makes some changes that are not compatible with that PR.
* This PR is an incremental update, without any significant semantic changes (except adding the notion of GAUGE), from the current state, more changes will be added in the future to resolve the TODOs.

Signed-off-by: Bogdan Drutu <[email protected]>
@jmacd
Copy link
Contributor Author

jmacd commented Jul 29, 2020

See #182.

@jmacd jmacd closed this Jul 29, 2020
bogdandrutu added a commit that referenced this pull request Jul 30, 2020
…tails about the aggregation and temporality. (#182)

* Change Metric type to be a more detailed structure with details about the aggregation and temporality.

This PR takes a more descriptive approach where the Aggregation (the last applied aggregation if any) is clearly defined and Temporality is available only where it makes sense. This can help clearly identify what are the possible values and properties for different types of Aggregations.

There are some things that can be considered (TODOs left in the code):

* open-telemetry/opentelemetry-specification#725
* Histogram/Summary sum - monotonicity?
* Previous aggregation measurements: raw measurements or "derived" measurements (results of another aggregation).
* Support for RawMeasurements (recorded via the Sync Instruments)
* Decide if support for INSTANTANEOUS temporality is still needed.

IMPORTANT:
* This PR is not equivalent with #168 or #181, this is inspired by these PRs but makes some changes that are not compatible with that PR.
* This PR is an incremental update, without any significant semantic changes (except adding the notion of GAUGE), from the current state, more changes will be added in the future to resolve the TODOs.

Signed-off-by: Bogdan Drutu <[email protected]>

* Address feedback, added more TODOs and created issues

Signed-off-by: Bogdan Drutu <[email protected]>

* Update opentelemetry/proto/metrics/v1/metrics.proto

Co-authored-by: Aaron Abbott <[email protected]>

* Update opentelemetry/proto/metrics/v1/metrics.proto

Co-authored-by: Tyler Yahn <[email protected]>

* Update opentelemetry/proto/metrics/v1/metrics.proto

Co-authored-by: Tyler Yahn <[email protected]>

* Update opentelemetry/proto/metrics/v1/metrics.proto

Co-authored-by: Tyler Yahn <[email protected]>

* Update opentelemetry/proto/metrics/v1/metrics.proto

Co-authored-by: Tyler Yahn <[email protected]>

* Update opentelemetry/proto/metrics/v1/metrics.proto

Co-authored-by: Tyler Yahn <[email protected]>

* Fix indentation and comment for Type

Signed-off-by: Bogdan Drutu <[email protected]>

Co-authored-by: Aaron Abbott <[email protected]>
Co-authored-by: Tyler Yahn <[email protected]>
@lubingfeng
Copy link

I sure hope we have resolved the issues and can get these changes merged in 2 weeks. @open-telemetry/specs-metrics-approvers Let's Really Do This.

This is great. I plan to attend this Thursday's SIG meeting for metrics and would be good to hear latest progress / status on those four pull requests:
#168
#170
#159
#171

I see the closure of #168, #170. #159 is still in draft stage while #171 is merged. Are we close to get #159 and #171 closed this week or next week?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants