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
It's a bit hard to reason about, and if the method opened up changing the implementation to a different one like exponential histogram in the future, it could make sense, but AFAIK the behavior would change so drastically (including the export SDK data type) that such a change couldn't actually be made. So we can probably just stick to explicit factories.
Then, we could either have explicitBucketHistogram() and exponentialHistogram(), or histogram() and exponentialHistogram(). I have a slight preference for the latter since I think most people will grok that a "standard histogram" is a fixed buckets one. If we had a full understanding of exponential histogram and many backends supported it, then histogram() and explicitBucketHistogram() could also be OK, but I think that's a bit too much for a V1, we should probably stick closer to current user expectations.
The text was updated successfully, but these errors were encountered:
The best histogram language comes from the sdk spec. I agree that its hard to reason about, but also think that exponential histograms will likely be a much better default than explicit bucket in the long run because of their ability to represent distributions well at a wide range of scales.
Here's some discussion around the the original introduction of the "best histogram" language. It seems ideal if the SDK could reserve the right to switch to exponential histograms when they become available, but share your concern that that the change would be so drastic that it may not be possible. It may be worth discussing at the spec level since this type of behavioral change from explicit -> exponential would affect all languages.
First is I think we can remove this method that returns an abstract "best histogram"
https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/view/Aggregation.java#L70
It's a bit hard to reason about, and if the method opened up changing the implementation to a different one like exponential histogram in the future, it could make sense, but AFAIK the behavior would change so drastically (including the export SDK data type) that such a change couldn't actually be made. So we can probably just stick to explicit factories.
Then, we could either have
explicitBucketHistogram()
andexponentialHistogram()
, orhistogram()
andexponentialHistogram()
. I have a slight preference for the latter since I think most people will grok that a "standard histogram" is a fixed buckets one. If we had a full understanding of exponential histogram and many backends supported it, thenhistogram()
andexplicitBucketHistogram()
could also be OK, but I think that's a bit too much for a V1, we should probably stick closer to current user expectations.The text was updated successfully, but these errors were encountered: