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

Minimum-memory-usage temporality preference for OTLP exporter #2738

Closed
jmacd opened this issue Aug 17, 2022 · 7 comments · Fixed by #2961
Closed

Minimum-memory-usage temporality preference for OTLP exporter #2738

jmacd opened this issue Aug 17, 2022 · 7 comments · Fixed by #2961
Assignees
Labels
spec:metrics Related to the specification/metrics directory triaged-accepted The issue is triaged and accepted by the OTel community, one can proceed with creating a PR proposal

Comments

@jmacd
Copy link
Contributor

jmacd commented Aug 17, 2022

What are you trying to achieve?

In open-telemetry/opentelemetry-java#4680, users are looking for an easy way to configure the minimum-memory settings. This means choosing delta temporality for synchronous instruments and cumulative temporality for asynchronous instruments.

I propose the name "stateless". Lightstep implements this setting in its OTel launcher, because this configuration works well for Lightstep. This update applies to the OTLP exporter specification.
.

Additional context.

This was discussed in #2404.

@jmacd jmacd added the spec:metrics Related to the specification/metrics directory label Aug 17, 2022
@jack-berg
Copy link
Member

Seems reasonable if there is demand for it 👍

Presumably this would be a setting for the OTLP metric exporter?

@jmacd jmacd changed the title Minimum-memory-usage temporality preference Minimum-memory-usage temporality preference for OTLP exporter Aug 17, 2022
@bogdandrutu
Copy link
Member

+1 for this, I was also confused when the predefined "delta" preference does not do all deltas (up down are not delta), or "stateless". It does a "hybrid" whatever I believe delta :))

@reyang
Copy link
Member

reyang commented Aug 17, 2022

+1

@rbailey7210 rbailey7210 added the triaged-accepted The issue is triaged and accepted by the OTel community, one can proceed with creating a PR proposal label Aug 19, 2022
@jmacd
Copy link
Contributor Author

jmacd commented Nov 9, 2022

+1 for this, I was also confused when the predefined "delta" preference does not do all deltas (up down are not delta), or "stateless". It does a "hybrid" whatever I believe delta :))

@bogdandrutu thank you for raising the question about UpDownCounter. The current OTLP Exporter preference spec is:

The recognized (case-insensitive) values for OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE are:

  • cumulative: Choose cumulative aggregation temporality for all instrument kinds.
  • delta: Choose Delta aggregation temporality for Counter, Asynchronous Counter and Histogram instrument kinds, choose Cumulative aggregation for UpDownCounter and Asynchronous UpDownCounter instrument kinds.

To me, these rules follow from the API's description of the purpose of the instrument, which is to calculate totals from incremental updates. Practically speaking, the reason we wrote these rules is to ensure that vendors and systems can safely translate UpDownCounter instruments into Gauge data points if they do not recognize non-monotonic sum timeseries.

I would keep the exception, that is to say the "stateless" or "hybrid" (if you will) temporality will be written as:

  • stateless: Choose Delta aggregation temporality for synchronous Counter and Histogram instruments, choose Cumulative aggregation for synchronous UpDownCounter instruments and both asynchronous counter instruments.

Now we can see why "stateless" isn't ideal, because it means "only the obligatory state", it's the minimum memory configuration we can reach without destroying the UpDownCounter instrument.

@tigrannajaryan
Copy link
Member

tigrannajaryan commented Nov 9, 2022

Not to distruct from this discussion, but I am curious about something related: in the "non minimum memory usage" setting do we attempt to still limit the memory usage in any way by purging the state for the least used timeseries?

@jmacd
Copy link
Contributor Author

jmacd commented Nov 9, 2022

@tigrannajaryan this is absolutely related, see also the update here #1891 (comment).

@tigrannajaryan
Copy link
Member

@tigrannajaryan this is absolutely related, see also the update here #1891 (comment).

What a timing, you posted that just 20 mins before I asked :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:metrics Related to the specification/metrics directory triaged-accepted The issue is triaged and accepted by the OTel community, one can proceed with creating a PR proposal
Projects
None yet
6 participants