Closed jmacd closed 3 years ago
Is the proposal more general to include bitemporal modeling that could be used as hints to time the computing of recording rules when data is updated/late ?
@jeromeinsf If I understand your use of the term correctly, this is probably not the conversation bitemporal modeling you're looking for.
This "Created" or "Start" timestamp is used to support knowing when a cumulative series was reset.
Your question @jeromeinsf relates to late-arriving data, and this is definitely an important discussion. Right now, especially in this working group, we are focused on a pull-based metrics, and Prometheus uses "staleness markers" to consistently indicate missing data. I see two follow-on questions for push-based systems
This has been clarified and we will account for this in our data model.
The OpenMetrics specification states for Counter metrics:
The OpenTelemetry data model agrees that this field is useful, and that it should be optional. We have argued that when the Created / Start time is not set, it is possible to miss process restarts, and thus undercount metrics for short-lived processes.
We are trying to define the proper translation into OTLP for metric points when the Created time is not known. This is relevant in https://github.com/lightstep/opentelemetry-prometheus-sidecar, which reads the WAL and writes OTLP metric streams. We believe that a Created / Start time can be filled in by any stateful observer that is able to remember the last value and its timestamp.
When a stateful observer possesses this information, we believe that processor SHOULD fill in the missing start timestamp.
The issue here is investigatory. Does Prometheus have plans to use the OpenMetrics Created timestamp and eventually include that in its WAL?