-
Notifications
You must be signed in to change notification settings - Fork 259
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 Monotonic Types #145
Add Monotonic Types #145
Conversation
Knowing the monotonicity of metric data enables receivers to implement certain algorithms to calculate the rate of change of the data. As such, this is an important quality to describe and is added to the `MetricDescriptor`. *Note on English*: NONDECREASING is used to describe values that either increase or remain constant over time. The English term "increasing" is not used as it does not encompass values that remain constant over time. A comment is added to identify the omission of NONINCREASING and information on how to notify it is needed should that arise in the future.
With 3 different enums we now use 3x32=96bits to encode 6 bits worth of info. This can have significant impact on memory consumption in Collector which may hold many thousands or even millions of metrics in queues. Should we use a single field with bitmasks instead? We can keep the enums and just use a single uint32 with lots of reserved fields for future use. |
@tigrannajaryan I see that as an optimization, which I think we can do it as a next step after we finalize the data format and all the properties we need. |
@MrAlias @bogdandrutu can we move forward with this? We are waiting for the finalization of metrics ProtoBufs to be able to use them in the Collector. |
Sorry, was blocked working on open-telemetry/opentelemetry-collector-contrib#229 for a few days, but will get back to this today. Talking with @bogdandrutu last week it sounds like two things (related to this PR) should be done:
Going to update later to remove the
There was an idea to include a |
Looks like @jmacd has also been thinking about this: #125 (comment). Going to wait until after the Metric SIG meeting today to make any changes to make sure we are all in sync. |
I think we found resolution today in the SIG call. |
@jmacd can you document the proposed resolution? |
@bogdandrutu : The plan is to go with:
thoughts? |
Instead of including a monotonic refinement, specify where applicable to the type.
Can you please update the description? |
Add the following types:
MONOTONIC_INT64
MONOTONIC_DOUBLE
These type values are still transported in the same DataPoints as their non-monotonic counterpoints, but add the significance to their values as being monotonic.
This is a partial replacement of #137
Relates to #125