Is knowing that a Histogram/Summary sum is monotonic important?

[bogdandrutu]

Currently there is a TODO in the metrics proto that needs a decision:

// TODO: Decide if knowing that the Sum is monotonic is important or not

[hdost]

This looks as if in the v1 of the protospec that this comment is gone which makes me think that this has been decided?

[bogdandrutu]

@jmacd I think we need this for the Histogram (probably for Summary as well), because currently OpenMetrics requires us to not send the Sum if values can be negative. We may want to discuss this in the Prometheus wg.

[jsuereth]

@bogdandrutu Can you comment on (a) if this is still an issue given the TODO is now gone and (b) how we resolve it.

Proposal from DataModel SiG:

• For OM / Prometheus export, ignore SUM if there are negative bucket values.

[bogdandrutu]

@jsuereth that is not 100% correct for the export. Reason is that I may not have a negative bucket defined but I may still have negative measurements, so the sum may still not be a Counter.

[jsuereth]

We discussed this in the DataModel SiG.

• For now sums will be exported as Counters (high compatibility with prometheus)
• We'd like to allow the use case of negative values in Histograms.
• We think we can provide some kind of semantic hint/detail outlining this scenario in the future in a non-breaking way.
  e.g. a is_non_monotonic boolean field that defaults to false.

[jsuereth]

So diving into this further, OpenMetrics defines two types of histograms with subtle differnces:

• Histograms, those that measure distributions of discrete events (e.g. latency of HTTP requests)
• GaugeHistograms, those that measure current distributions (e.g. how long items have been waiting in a queue).

For the first, prometheus/OpenMetrics requires that all sums are monotonic and all measurements positive values from discrete events. For the second, you just grab what you found, which can include negative values. Aggregation for "GaugeHistogram" matches aggregation for Gauge

I believe @jmacd wants to model the second type of histogram as an "instantaneous temporality" histogram. It's also possible we could allow a histogram-data-point to be exported from Gauge to accommodate this. However, I want to make it clear we are NOT solving that problem with this bug. We are only focused on making sure we know when it is safe to convert from an OTLP Histogram to an OpenMetrics Histogram.

So, re-affirming the SiGs decision and casting a few lights on things that weren't clear to me until I got caught up on details from Start-Time-Discussions:

1. Whether or not we allow negative measurements to participate in a distribution of a Histogram is an orthogonal discussion to instantaneous temporality or the notion of "GaugeHistogram" from open metrics. We can and should figure out how to support those, but we can do so in a non-breaking way.
2. If we have a Histogram of discrete events with negative measurements we cannot export this to OpenMetrics/Prometheus. I'm not sure we know what to do here. The SiG decided that we enforce Histograms have positive values for now and we can figure out how to support negative measurements going forward, in a non-breaking way. This means (for now) all OTLP cumulative histograms can convert directly to OpenMetrics/Prometheus.

To resolve this bug, I'm adding description to the histogram OTLP proto to require non-negative measurements for now. We can expand support for more histogram types going forward.