See also https://prometheus.io/docs/specs/native_histograms/#opentelemetry-interoperability
I note that native histograms have exponentially-varying sizes. In principle, if you set the factors appropriately (e.g. say scaling of 1.1 = each bucket is 10% larger than the next) then the answers you get for min and max should be within 10% of the actual answer. But you won't get the *exact* minimum or maximum which is what you were asking for. On Monday, 23 June 2025 at 22:13:56 UTC+1 Brian Candler wrote: > On Monday, 23 June 2025 at 14:31:34 UTC+1 tejaswini vadlamudi wrote: > > but with histograms, mainly with Native Histograms, is there a possibility > to get Max and Min values for a period of time? > > > No. If that's not clear from my explanations so far, then I have not done > a very good job. > > > > With OTEL-based metrics instrumentation, it is possible to record max and > min values. See > https://opentelemetry.io/docs/specs/otel/metrics/data-model/#histogram > > > Please read the link I posted before: > > https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/33645 > especially the last comment: > > https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/33645#issuecomment-2514894327 > > The OTEL histogram's way of reporting max/min values are not compatible > with Prometheus. Prometheus histograms are cumulative: that is, they never > reset. They are just counters which keep incrementing forever. If they had > a min/max then it would be the min/max over all time, which is not useful. > > You can create a separate timeseries for min/max, but it would not be part > of the histogram. It would either have to be min/max over successive > timeslots (e.g. 1 minute intervals), or min/max over a sliding window > (which is expensive, as you've have to buffer all the samples for that time > window). > > > I think histogram_quantile(0, rate(http_request_duration_seconds[1m])) > will give me min value. Is it correct? > > No, it's not. Again, it seems I have not been explaining this well. > > Let's say your histogram buckets are: > > 0-10ms (le="0.01") > 10-20ms (le="0.02") > 20-30ms (le="0.03") > 30-40ms (le="0.04") > 40-50ms (le="0.05") > 50ms+ (le="inf") > > A sample comes in with request time of 12.3ms, and this is the fastest > over the time period of interest. > > All this does is add 1 to the 10-20ms bucket (counter) in the histogram. > The actual value of 12.3ms is LOST. The only thing you will know from > looking at the histogram is that the 10-20ms bucket has incremented, but > the 0-10ms bucket has not, and therefore the minimum value is somewhere > between 10ms and 20ms. If you use the histogram_quantile(0...) formula you > showed, the answer will be "0.01", which I also explained previously with a > worked example. This tells you "the minimum value is at least 10ms" - and > implicitly not more than 20ms, as that's where the next bucket starts. > > I think I had better hand over to someone else now. > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/prometheus-users/dab2ab1c-2cf9-4a28-91bc-6c7a8c4dddffn%40googlegroups.com.
