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

Add Exemplar support to Metrics proto #159

Merged
merged 5 commits into from
Aug 13, 2020

Conversation

cnnradams
Copy link
Member

Adds support for OTEP#113. This should also handle duplicate labels in exemplars by bringing labels up a level and making exemplars only hold additional_labels.

Proto question (since I'm new to this): I defined a measurement_type enum for the RawValue type, but couldn't create a new enum with just INT64 and DOUBLE (because I can't share names with other enums). So right now I'm using Type, which means things other than INT64 and DOUBLE can be picked for measurement_type. What is the right solution for this?

@cnnradams
Copy link
Member Author

Closing in favor of #162 (which implements exemplars)

@cnnradams cnnradams closed this Jul 9, 2020
jmacd pushed a commit to jmacd/opentelemetry-proto that referenced this pull request Jul 15, 2020
jmacd pushed a commit to jmacd/opentelemetry-proto that referenced this pull request Jul 15, 2020
@jmacd jmacd reopened this Jul 18, 2020
@jmacd jmacd marked this pull request as draft July 18, 2020 08:17
@jmacd
Copy link
Contributor

jmacd commented Jul 18, 2020

I reopened this and put it in draft state. This has been referred to heavily in #168, and after #168 merges this PR should be restored to roughly its original state.

@cnnradams
Copy link
Member Author

updated to not make structual changes and to add raw_value_data_points. Still need to specify the type of RawValue in some way, which will be unblocked after #168

@@ -104,6 +133,7 @@ message Metric {
repeated DoubleDataPoint double_data_points = 3;
repeated HistogramDataPoint histogram_data_points = 4;
repeated SummaryDataPoint summary_data_points = 5;
repeated RawValue raw_data_points = 6;
Copy link
Member

Choose a reason for hiding this comment

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

I think this should be removed for the moment, this is not exemplar, is supporting "RawMeasurements" which is out of scope for this PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

removed

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

The generated code was removed, please remove that as well. Rebase the PR please.

@cnnradams cnnradams marked this pull request as ready for review August 5, 2020 19:18
@cnnradams cnnradams requested review from a team August 5, 2020 19:18
opentelemetry/proto/metrics/v1/metrics.proto Show resolved Hide resolved
message RawValue {
// The set of labels that were dropped by the aggregator, but recorded
// alongside the original measurement. Only labels that were dropped by the aggregator should be included
repeated opentelemetry.proto.common.v1.StringKeyValue labels = 1;
Copy link
Member

Choose a reason for hiding this comment

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

What is the relationship between these labels and the labels in the DataPoint:

  • Do we duplicate them?
  • Do we extract these labels and the actual set of labels is the combination of these + datapoint.lables?

Copy link
Member Author

Choose a reason for hiding this comment

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

For exemplars these labels are only the labels not included in the DataPoint's labels. I would change this field to be dropped_labels but if RawValue is used as a data point itself the labels would include all labels

Copy link
Member

Choose a reason for hiding this comment

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

@jmacd I know you tried to share the messages, can you help define the behavior here?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you recommended calling these "dropped_labels". This sounds good to me.

opentelemetry/proto/metrics/v1/metrics.proto Show resolved Hide resolved
@lubingfeng
Copy link

@jmacd When can we get #159 and #171 closed, which are blockers for getting stats proposal finalized, based on discussion two weeks ago.

@bogdandrutu
Copy link
Member

@lubingfeng

@jmacd When can we get #159 and #171 closed, which are blockers for getting stats proposal finalized, based on discussion two weeks ago.

Not sure I understand:

  • 159 is this PR
  • 171 is merged

opentelemetry/proto/metrics/v1/metrics.proto Outdated Show resolved Hide resolved

// (Optional) List of exemplars collected from
// measurements that were used to form the data point
repeated RawValue exemplars = 7;
Copy link
Member

Choose a reason for hiding this comment

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

Would this just be a list of random samples from the whole window? Open question in the OTEP:

We don’t have a strong grasp on how the sketch aggregator works in terms of implementation - so we don’t have enough information to design how exemplars should work properly.

Copy link
Member Author

Choose a reason for hiding this comment

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

The proto does not define how the exemplars were sampled, not sure your question?

Copy link
Member

Choose a reason for hiding this comment

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

Nvm, I see now

Copy link
Contributor

Choose a reason for hiding this comment

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

At the recent OTLP discussion meeting, we agreed to remove the sample_count field from the current proposal. We also agreed to move the Exemplars into the DataPoints so that they can refer to dropped labels, not include full label sets in each point.

Copy link
Contributor

Choose a reason for hiding this comment

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

@bogdandrutu does this sound right to you, for now?

Copy link
Member

Choose a reason for hiding this comment

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

We also agreed to move the Exemplars into the DataPoints so that they can refer to dropped labels, not include full label sets in each point.

I think we agreed that you will evaluate what is better for performance/semantics:

  1. Having a repeated RawValue exemplars in the Metric that applies to all data points (user may need to do another remapping to every data point) vs repeated RawValue exemplars in every point (if we go with every point then "dropped_labels" is better name for that).

My point is that I don't have a strong opinion between the both, and was trying to make you investigate and decide which way. Here are my thoughts:

  • Having repeated RawValue exemplars in the Metrics:
    • Pros:
      • Saves some memory in the internal representation (have extra 24 bytes per data point).
      • Same message may be able to be re-used with raw-measurements because labels don't represent dropped.
    • Cons:
      • Duplicate labels on the wire.
      • User needs to re-map every exemplar to the data point by doing the labels matching.

I feel cons are more "significant" than pros, so personally I would go with exemplars in every DataPoint as you suggested.

Copy link
Member

Choose a reason for hiding this comment

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

If we go with exemplars in every DataPoint I would say to rename the message to "Exemplar" :)

Copy link
Contributor

Choose a reason for hiding this comment

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

This discussion makes me want a way to intern label sets to avoid the "re-map every exemplar" problem.

I don't feel inclined to invest time in this now, so we should probably choose "repeated RawValue exemplars in every point".

Copy link
Member

Choose a reason for hiding this comment

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

This discussion makes me want a way to intern label sets to avoid the "re-map every exemplar" problem.

Even with an "intern label" you still need to map every exemplar to a point (that mapping may be faster if we have "intern label" but still needs some work)

@jmacd
Copy link
Contributor

jmacd commented Aug 8, 2020

I left a lengthy remark on this topic here:
open-telemetry/opentelemetry-specification#617 (comment)

I am worried that my request for @cnnradams to explore and implement statistical sampling for exemplars has led to some confusion, and (with my apologies) I am willing to omit it, but as noted in the comment, there are many related questions and even if we take the statistical question out of it, we're left with tough questions.

@jmacd
Copy link
Contributor

jmacd commented Aug 12, 2020

@cnnradams I know your internship is over, but let us know if you're willing to make these changes.

@cnnradams
Copy link
Member Author

sure. from reading the discussion, it seems like the only things I need to change are RawValue -> Exemplar, labels -> dropped_labels, and remove sample_count? Since there is already an exemplar set per datapoint?

@cnnradams
Copy link
Member Author

sure. from reading the discussion, it seems like the only things I need to change are RawValue -> Exemplar, labels -> dropped_labels, and remove sample_count? Since there is already an exemplar set per datapoint?

done all 3.

Copy link
Contributor

@MrAlias MrAlias left a comment

Choose a reason for hiding this comment

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

🚀

@bogdandrutu bogdandrutu merged commit 7b33f20 into open-telemetry:master Aug 13, 2020
bogdandrutu pushed a commit to bogdandrutu/opentelemetry-proto that referenced this pull request Aug 13, 2020
* Add exemplars to proto

* handle just exemplars, nit fixes

* comments

* rawvalue -> exemplar, remove sample_count
bogdandrutu pushed a commit to bogdandrutu/opentelemetry-proto that referenced this pull request Aug 13, 2020
* Add exemplars to proto

* handle just exemplars, nit fixes

* comments

* rawvalue -> exemplar, remove sample_count
bogdandrutu added a commit that referenced this pull request Aug 13, 2020
* Add exemplars to proto

* handle just exemplars, nit fixes

* comments

* rawvalue -> exemplar, remove sample_count

Co-authored-by: Connor Adams <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants