Closed jmacd closed 1 year ago
Seems reasonable if there is demand for it 👍
Presumably this would be a setting for the OTLP metric exporter?
+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 :))
+1
+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.
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?
@tigrannajaryan this is absolutely related, see also the update here https://github.com/open-telemetry/opentelemetry-specification/issues/1891#issuecomment-1309089908.
@tigrannajaryan this is absolutely related, see also the update here #1891 (comment).
What a timing, you posted that just 20 mins before I asked :-)
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.