Description
The purpose and use-cases of the new component
Some receivers (e.g. prometheus) can produce metrics without a start time. It would be helpful to have a way to properly set the start time for cumulative metrics where the start time is not known.
The way this is typically done (e.g. in the googlecloud exporter here, or in this out-of-tree "noramlizesums" processor)) is by dropping the first point in a timeseries without a start timestamp and recording its timestamp and value. Subsequent points use the timestamp of the initial point as the start timestamp, and "subtract" the initial value from the value of the subsequent point. This results in the time range [start, end] properly accounting for the value of the cumulative within that range.
It comes with a downside: while rates are now accurate, the absolute value of a counter is lower than what it would be otherwise. Generally speaking, the cumulative value of a counter is not particularly important--the rate is what matters.
This component could be represented using a processor, receiver helper, or exporter helper.
A receiver helper could make sense, since only a limited number of receivers can produce metrics without a start time (PRW, OTLP, Prometheus come to mind). An exporter helper could also make sense, as whether or not a start time is necessary at all is probably determined by the destination. But since this processor involves a lot of caching, it would be inefficient to have these caches not be shared (and it isn't necessarily safe to share).
Overall, I think a processor makes the most sense, as it can be inserted before exporters that require start time, and guarantees that all metrics passing though have a correct one set.
Example configuration for the component
The component will not require any configuration. E.g.
processors:
metricstarttime:Telemetry data types supported
Metrics
Code Owner(s)
Sponsor (optional)
Additional context
I would love for this to replace some of the complex start time handling logic that is currently embedded in the Prometheus receiver. It seems like a separate component would be more self-contained and would be able to apply to PRW as well as the Prometheus receiver. Let me know if you are interested in collaborating