open-telemetry / opentelemetry-specification

Specifications for OpenTelemetry
https://opentelemetry.io
Apache License 2.0
3.71k stars 887 forks source link

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

Closed jmacd closed 1 year ago

jmacd commented 2 years ago

What are you trying to achieve?

In https://github.com/open-telemetry/opentelemetry-java/issues/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.

jack-berg commented 2 years ago

Seems reasonable if there is demand for it 👍

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

bogdandrutu commented 2 years ago

+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 commented 2 years ago

+1

jmacd commented 1 year ago

+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:

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 commented 1 year ago

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 commented 1 year ago

@tigrannajaryan this is absolutely related, see also the update here https://github.com/open-telemetry/opentelemetry-specification/issues/1891#issuecomment-1309089908.

tigrannajaryan commented 1 year ago

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

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