You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The HistogramValue Bucket supports one exemplar per bucket, with exemplar values being restricted to string-valued attributes. This is particularly restrictive, for a number of reasons:
It's not possible to provide exemplars for non-histograms
It's not possible to provide more than one exemplar per bucket
It requires converting certain data types to a string, which will require additional specification
Update metric descriptor to contain information on the data qualities.
This includes:
- The meaning of the time interval measurements were made over is now
described by the `interval` value.
- The monotonic nature of the data is captured if known.
- If the data values are restricted to a subset of numbers.
The `SummaryDataPoint` and `HistogramDataPoint` were merged into a
unified `Distribution` message that contains statistics about the
observed population of values.
Adds support for multiple histogram bucket definitions and adds a linear
bucket definition message.
Includes an explicit minimum and maximum for a `Distribution` (open-telemetry#122).
Removes the exemplar code (open-telemetry#81). This can be added back in as a more
generalized case now given the new `Data` structure of the Metrics. But,
it has been left for a separate PR.
Unifies the common parts of the previous `*DataPoints` into a unified
`Data` message.
This is not complete. It likely needs better names and it certainly
needs comments.
Related to open-telemetry#125
Fixes to open-telemetry#81
The HistogramValue Bucket supports one exemplar per bucket, with exemplar values being restricted to string-valued attributes. This is particularly restrictive, for a number of reasons:
I would remove this support entirely until a full set of requirements can be drafted. (1) It's meaningful and reasonable to support encoding exemplars for any kind of metric instrument. (2) It's certainly useful to provide more than one exemplar per instrument/value-range, as a means of conveying a sample distribution, (3) There is a common request (e.g., open-telemetry/opentelemetry-specification#381, https://kccncna19.sched.com/event/UaXX/deep-linking-metrics-and-traces-with-opentelemetry-openmetrics-and-m3-rob-skillington-chronosphere) to include trace context in these exemplars, and forcing them to be encoded as string-attribute lists is onerous (and inefficient)--probably trace context should be specialized.
The text was updated successfully, but these errors were encountered: