Should HistogramTimeSeries be called HistogramOfDoublesTimeSeries? about opentelemetry-proto HOT 8 CLOSED

@jmacd this issue is about the sum field in Histogram and value field in Exemplar. They are both double in this repo and also in OpenMetrics proto too.
The question is: do we need another Histogram type where these fields are int64? We have this distinction for Gauge and Counter types but not for Histogram currently.
You are right that double can represent a large subset of integers (albeit it may work slower if you do arithmetics). I tend to agree with you that another Histogram type is unnecessary but I don't know how the Histogram is used at the destinations to have a more substantial opinion.

Exact histograms will contain integer counts in each bin, whether they originate from an int or a float instrument. Approximate histograms will contain floating point counts in each bin, whether they originate from an int or a float instrument.

This is related but probably a separate issue. Do we want to be able to represent approximate histograms?

from opentelemetry-proto.

@jmacd @bogdandrutu @tigrannajaryan should we just do it just in case?

from opentelemetry-proto.

I'm a bit confused. A metric instrument has a number kind, int or float. A measure instrument may produce a histogram. Exact histograms will contain integer counts in each bin, whether they originate from an int or a float instrument. Approximate histograms will contain floating point counts in each bin, whether they originate from an int or a float instrument.

Regardless, I think we should use something structurally equivalent to the OpenMetrics protocol unless there's a very good reason, and if there's a very good reason we should try to convince them to update their protocol, which isn't quite finalized. For instance, the OpenMetrics protocol doesn't allow floating point counts in their buckets, so it can't represent an approximate histogram without additional rounding errors. I'm not inclined to lobby for this now.

OpenMetrics histogram exemplars do contain floating point exemplars. I think this is fine, because float64 can represent exact integers up to 2^53+1. Remember that the metrics descriptor will still say whether the instrument accepted floats or integers, so we should not need explicit integer histogram types unless it's really about representing integers above 2^53+1, and I doubt that matters.

from opentelemetry-proto.

For the record, I'm referring to this version of the OpenMetrics proto: https://github.com/OpenObservability/OpenMetrics/blob/sbhola/proto/proto/openmetrics_data_model.proto

from opentelemetry-proto.

Do we want to be able to represent approximate histograms?

I do.

To be clear, this issue is completely detached from the current OTel user-facing API. but in existing statsd user-facing APIs, each update takes a weight to indicate that sampling was performed. We haven't addressed sampling and metrics in OTel (yet).

The use-case I've seen is that we're issuing metrics derived from sampled spans (e.g., compute a histogram of latency using spans that were sampled). Imagine spans are sampled with probability 2/5, then each count derived from that span would have an effective weight of 5/2 in the most simple accounting, and floating point counts are needed.

from opentelemetry-proto.

@jmacd the linked proto is not the current state. Check the open PR OpenObservability/OpenMetrics#126 for that.

from opentelemetry-proto.

My understanding there is no plans to have Int64 histogram. So no need to rename HistogramDataPoint to DoubleHistogramDataPoint to account for a future change. Closing. Please re-open if this is not the case

from opentelemetry-proto.

My understanding there is no plans to have Int64 histogram. So no need to rename HistogramDataPoint to DoubleHistogramDataPoint to account for a future change. Closing. Please re-open if this is not the case

from opentelemetry-proto.