Attaching timestamp to metrics

[dorimon-1]

Hi there,
Im looking for a way to retroactively send metrics by attaching a timestamp to my metric.
To my understanding prometheus as the ability to scrape with a custom timestamp, but i cant figure how to add them initially

[smith]

Can you set observed_timestamp? for this?

[dorimon-1]

not sure about observed_timestamp, didnt find anything about it regarding to metrics, only logs.
What I'm really looking for is having time_unix_nano changed.
currently the only solution i have is very hacky, I add a label with the timestamp upon record, and when sending metrics to otel via manualReader I have a process that remove that label and modifies the timestamp to the removed value, also have a out of order settings in prometheus to have that all work together

[LarryHu0217]

There is currently no supported per-measurement timestamp argument in the OpenTelemetry JS Metrics API. For example, Counter.add(), Gauge.record(), and Histogram.record() accept a value, attributes, and an optional context, but not a timestamp. The SDK owns the timestamps of the aggregated metric points.

observed_timestamp is a Logs data-model field, so it does not apply to metric instruments. Likewise, changing time_unix_nano after collection in a MetricReader or exporter bypasses the SDK's aggregation/temporality semantics and can create overlapping or out-of-order series.

For historical data I would separate the use cases:

• If these are historical events, emit logs (or span events) with their original timestamps and derive metrics in the Collector/backend.
• If they are already aggregated historical metric points, import them as OTLP metric data through a dedicated importer/Collector receiver, where each data point explicitly carries time_unix_nano and the correct start_time_unix_nano.
• For normal live application instrumentation, record through the Metrics API and let the SDK assign the point timestamps.

Prometheus accepting explicit sample timestamps does not add an equivalent timestamp parameter to the OTel Metrics API, and accepting old/out-of-order points remains a backend-specific concern.

References:

• OpenTelemetry JS metric instrument API
• OpenTelemetry metrics data model