Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify OTLP Metrics exporter requirements #2715

Open
jmacd opened this issue Aug 5, 2022 · 4 comments
Open

Clarify OTLP Metrics exporter requirements #2715

jmacd opened this issue Aug 5, 2022 · 4 comments
Assignees
Labels
[label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR spec:metrics Related to the specification/metrics directory

Comments

@jmacd
Copy link
Contributor

jmacd commented Aug 5, 2022

What are you trying to achieve?

Some questions have come up, for example: open-telemetry/opentelemetry-js#3105 (comment)

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 jmacd added the spec:metrics Related to the specification/metrics directory label Aug 5, 2022
@rbailey7210 rbailey7210 added the [label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR label Aug 12, 2022
@pirgeo
Copy link
Member

pirgeo commented Aug 16, 2022

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).

@alanwest
Copy link
Member

alanwest commented Aug 29, 2022

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
Copy link
Member

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.

@pirgeo
Copy link
Member

pirgeo commented Aug 30, 2022

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, #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

No branches or pull requests

5 participants