opentelemetry-specification icon indicating copy to clipboard operation
opentelemetry-specification copied to clipboard

Clarify OTLP Metrics exporter requirements

Open jmacd opened this issue 2 years ago • 4 comments

What are you trying to achieve?

Some questions have come up, for example: https://github.com/open-telemetry/opentelemetry-js/issues/3105#issuecomment-1197593270

What did you expect to see?

Questions that deserve to be answered for OTLP specifically:

  • When will Histogram Min/Max fields be set? Presumably for Delta temporality only.
  • Exporter required to not set Start Timestamp for Gauge data points? Presumably yes, start time must not be set for gauges.
  • When configured for Delta temporality, permitted to skip points with "no data"? Presumably yes, but needs clear definition.

The definition for "no data" means one thing for data points with temporality and another thing for gauges. For delta Sums/Histograms, no data means Sum == 0 or Count == 0. I believe exporters should not send data points with Sum == 0 (Sum) or Count == 0 (Histograms).

When it comes to specifying the synchronous gauges (#2707), I think we will require a statement that allows gauges to stop reporting when they have not been synchronously set in the preceding collection interval.

jmacd avatar Aug 05 '22 17:08 jmacd

A delta sum of 0 means "no change" IMO, not "no data". I feel like exporting 0 for unchanged delta exports is required, since it signals that the data stream is alive, but there is no change there (as opposed to the data stream breaking off when we stop to export). An example could be a UpDownCounter: Export, Add 5, subtract 3, subtract 2, export again. There was definitely something happening on the counter, it just happened to cancel out - skipping the export of that data point feels wrong to me.

I agree that for histograms it makes sense (since the histogram already aggregates data, and if the count is 0 there literally was no data there).

pirgeo avatar Aug 16 '22 08:08 pirgeo

An example could be a UpDownCounter: Export, Add 5, subtract 3, subtract 2, export again. There was definitely something happening on the counter, it just happened to cancel out - skipping the export of that data point feels wrong to me.

An UpDownCounter as exported over OTLP is normally exported as a non-monotonic sum with cumulative temporality (even when configured with a delta temporality preference), so shouldn't this mean we never skip export and always export the cumulative value at that time?

alanwest avatar Aug 29 '22 22:08 alanwest

For delta Sums/Histograms, no data means Sum == 0 or Count == 0. I believe exporters should not send data points with Sum == 0 (Sum) or Count == 0 (Histograms).

For what it's worth, .NET does not rely on value == 0 to determine "no data". We track a status for each metric point indicating whether it was updated or not during the most recent interval.

alanwest avatar Aug 29 '22 22:08 alanwest

An UpDownCounter as exported over OTLP is normally exported as a non-monotonic sum with cumulative temporality

I am not sure if this is always true for all SDKs. For example, https://github.com/open-telemetry/opentelemetry-specification/issues/2738 calls for exporting synchronous instruments as deltas. As far as I understand, that would also mean exporting synchronous UpDownCounters as Deltas (with potentially negative values). I am not sure if I am missing something, but I don't see this as a problem per se - the backend just has to be able to deal with negative Sum deltas.

pirgeo avatar Aug 30 '22 05:08 pirgeo