Can metric have it's own timestamp when registering a value?

[ThePlenkov]

Hi!

We'd like to use Open Telemetry SDK to register some metrics.

In our case metrics are recieved with a certain delay and the moment we create meter/metric is not the same when actual value was registered.

So since we use JS SDK i've created PR to allow to provide custom timestamp when adding/recording a value:
open-telemetry/opentelemetry-js#5273 (comment)

However this PR was rejected, because timestamp is not part of that specification but when I read the spec, i see that timestamp is the part of data points:

• https://opentelemetry.io/docs/specs/otel/metrics/data-model/#temporality

Every OTLP metric data point has two associated timestamps. The first, mandatory timestamp is the one associated with the observation, the moment when the measurement became current or took effect, and is referred to as TimeUnixNano. The second, optional timestamp is used to indicate when a sequence of points is unbroken, and is referred to as StartTimeUnixNano.

• https://opentelemetry.io/docs/specs/otel/metrics/data-model/#gauge

A timestamp when the value was sampled (time_unix_nano)

So how to interpret this, is timestamp part of the spec or not?

Thanks!

[ThePlenkov]

OK, it became now a bit more clear - what needs to be done. So the proposal is: methods add and record should allow to provide a custom timestamp. If time stamp is not provided, current timestamp is used.

What do you think about this?

[jsuereth]

Metrics are designed to be points aggregated BY the opentelemetry system. While this type of a feature could work for a Gauge, it wouldn't work (well) for any of the other metric points (which need both start and stop timestamps). Additionally, OpenTelemetry tries to limit memory usage of metrics, which is why it does its own aggregation and reports timestamps it calculates, on intervals specified by the metric-exporters (or by prometheus pull configuration).

If you need data with timestamps, using Logs/Events is a much better bet.