-
Notifications
You must be signed in to change notification settings - Fork 888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StartTime in Gauge is hard to understand/inconsistent #2244
Comments
The recommendation to use "the timestamp when a metric collection system started" was included as an option that would allow simultaneous producers of a Gauge to be detected by the system (i.e., that they are overlapping). Start time accomplishes this for all of the other points, so it was included for consistency. When a process restarts and there are briefly two producers of the same gauge, this allows consumers to tell which measurement is from a younger series. There is another way two timestamps might be used for gauges, where the start timestamp is the time the measurement was set (i.e., assuming a synchronous gauge instrument) and the "now" timestamp is the time the measurement was captured as the current one. Even if OTel adds a synchronous Gauge instrument, I do not prefer this interpretation. These two ways of using timestamp do not necessarily create confusion by co-existing. The StartTimestamp is always earlier in time, the Timestamp is always later in time. In both cases the metric had a value at through Timestamp, and "when did this value take effect?" requires history to disambiguate, but since we do not have a synchronous Gauge the point is practically irrelevant. I agree we should remove the default use of a start time for gauges from the image. I'm happy with the option to " timestamp when a metric collection system started", but if we think Gauge points shouldn't have the option of using two timestamps -- which I do not -- then we should remove one of the timestamp fields. |
I think the image is just wrong, so fixing the start time to match the specification is easy. Regarding whether to ignore The real question is whether we find value in Personally, I'm fine keeping it and evaluating usage. Given start_time on gauge is (necessarily) optional (so we can interact with other metric systems), I don't think it's a hard ask either way to keep or remove. I suggest we re-evaluate Gauge start_time after metric stability and adoption to see if it's paying off / is in use. |
Considering #2318, I think we should update the specification stating that start_timestamp is not used for Gauge data points. I also think we should add to the specification stating that exporters MAY use a single timestamp for the entire set of exported data, which means that Gauge timestamps will be the time of collection. IOW: We already state that all observations from a callback MUST use the same timestamp. I would like to add a statement that all observations from the SDK MAY use the same timestamp, and this pins down what the one timestamp of a Gauge data point means. |
There are multiple places where we refer to the start-time in a gauge data model description:
the timestamp when a metric collection system started.
What do I expect:
The text was updated successfully, but these errors were encountered: