Add development spec for per-timeseries start time tracking

[dashpole]

Fixes #4184

Prerequisite for #2232.

Changes

This adds requirements around start time handling for metrics SDKs:

• Consistently describe the start timestamp as "The start timestamp best represents the first possible moment a measurement for this timeseries could have been recorded."
• Start timestamp MUST be after intervals in which the timeseries was not reported.
• Cumulative synchronous instruments SHOULD use the first measurement time as the start timestamp

This also restates "the start timestamp MUST equal the previous interval's timestamp" from the data model specification to ensure it isn't read as requiring changes for Delta metrics.

The effect of this change is that all cumulative metrics SHOULD use at least the previous export interval for "new" timeseries. That should be very straightforward, as it is what is done for delta metrics today. I would love for this to be a MUST, but i'm concerned it could be considered breaking.

Additionally, SDKs SHOULD use the current timestamp for "new" timeseries. This could have a performance cost, so it isn't a MUST.

Omissions

While it is possible for delta metrics to track the attribute sets exported in the previous interval, it is expensive to do so because it requires tracking the attribute sets that were present in the previous collection interva. This would enable SDKs to differentiate between an "unbroken" series, and a "new" one to provide a more accurate start time when observing "new" series. I doubt this is something delta backends would care about enough to be worth the cost.

cc @ArthurSens @atoulme @jmacd

Prototypes

• Go: prototype for cumulative per-timeseries start timestamp opentelemetry-go#7719

[jmacd]

I like the language "best represents". There is not a universal approach here, and there are tradeoffs. "Best" can be subjective, I think, giving room for implementations to stay compatible.

Best may include:

• start time of the SDK
• first observation of the series
• last collection interval

It is important to leave this open because each has different requirements for memory, especially considering future changes to support remove().

[MrAlias]

Does this mean I need to ask the kernel when my process was created? Or, does this mean it is just whenever I get to initializing the metric system?

It also needs to be made clear this does not represent the time the thing being measured began (i.e. a car start time or manufacturer date when measuring an odometer reading)

[dashpole]

FWIW, I don't think i'm changing the specification here. I'm using the language already used for other instruments consistently for all instruments.

Fundamentally, all events that are part of an aggregation should occur between the start and end times.

Does this mean I need to ask the kernel when my process was created? Or, does this mean it is just whenever I get to initializing the metric system?

Depends on when the thing you are measuring starts. For a counter that starts counting when the process was created (e.g. container.cpu.time), it would be correct to use the time at which the process started. If the metric system is the system counting events, and starts from zero, then it is correct to use the start time of the metric system as the start time for metrics recorded after it starts.

It also needs to be made clear this does not represent the time the thing being measured began (i.e. a car start time or manufacturer date when measuring an odometer reading)

It could represent the time the thing being measured began. Either of the two listed are possibly correct, but if you use the car start time, then the aggregation should only include events that occur since the car started. I would be rather confused if my car's speed graph indicated that I went 10k mph pulling out of my driveway this morning because it reported that I had done my odometer's reading in the first 30 second interval :).

[ArthurSens]

Thanks for tackling this one :)