Fixes ExponentialBucketTimeRange causing unpredictable memory usage and Floating Points Prometheus Issue

[AkramBitar]

See issue: #1119

[mbrandenburger]

Thanks @AkramBitar for creating this fix. I am wondering if we could just use ExponentialBucketsRange from prometheus https://github.com/prometheus/client_golang/blob/v1.23.2/prometheus/histogram.go#L339

Here in this package we could just provide a adapter to match our time-based API. WDYT?

[AkramBitar]

Thanks @AkramBitar for creating this fix. I am wondering if we could just use ExponentialBucketsRange from prometheus https://github.com/prometheus/client_golang/blob/v1.23.2/prometheus/histogram.go#L339

Here in this package we could just provide a adapter to match our time-based API. WDYT?

Thanks a lot @mbrandenburger.

Prometheus's function requires min > 0 because it uses ratio-based math (max/min).

growthFactor = (max/min)^(1/(count-1))
bucket[i] = min * growthFactor^i

In our case measuring time durations starting from 0 (e.g., 0ms to 1000ms). For example:

NotifyStatusDuration: m.NewHistogram(metrics.HistogramOpts{
			Name:    "notify_status",
			Help:    "Histogram for the duration of notifyStatus",
			Buckets: utils.ExponentialBucketTimeRange(0, 1*time.Second, 10),
		}),

We can do one of the following:

1. Keep the current suggested implementation in this PR.
2. Change the current ExponentialBucketTimeRange to call Prometheus implementation, and change all the calls to this method to start from "1" and not from "0".
3. Change the current ExponentialBucketTimeRange to check if start == 0, then use "1" and call Prometheus implementation
   (Less recommended one for me).

Please let me know what do you think and I will change the code accordingly.

[mbrandenburger]

Thanks @AkramBitar. I think if the prometheus impl gives what we need (module some wrapper code), then we should consider to use it. WDYT?

[AkramBitar]

Thanks @AkramBitar. I think if the prometheus impl gives what we need (module some wrapper code), then we should consider to use it. WDYT?

I think lets leave this implementation since we need to keep "0" buckets and not to make a lot of changes in other components.

[mbrandenburger]

LGTM