Bound memory use of the cumulative sum aggregator

[MrAlias]

The cumulative sum Aggregator will never forget a sum for an attribute set, even if that set if never updated again.

This means that an unbounded amount of memory will be used by the SDK if there are unbounded number of attribute sets being used.

Ultimately this is a user problem, they need to not allow unbounded many attribute sets to be recorded. However, the SDK should attempt to optimize its performance and remove "state" sums it has.

TODO

• [ ] Determine what "stale" means. This will require looking at other implementation and might need a specification change/addition to ensure uniformity across OTel.
• [ ] Implement an algorithm for the cumulative sum Aggregator that forgets stale sums.

[jmacd]

I think that OpenTelemetry may want to specify a behavior for SDKs to agree on and implement. The data model features "no data present" flags for each data point, which can be used to signal the intentional end of a series--it would be appropriate to emit one of these no-data-present points for "a while" before forgetting the point entirely. The problem or difficulty is in determining what the new start time should be when the series is re-started. Not sure there's a "best" answer to this question.

[MrAlias]

I think that OpenTelemetry may want to specify a behavior for SDKs to agree on and implement.

Agreed. I also think in that agreement it need to specify what stale means. If one implementation defines stale as 5 cycles and another 2000 user behavior will be different.

Is this something you can work on in the specification @jmacd?

[jmacd]

I am interested in helping with this specification, but I would like to look to the Prometheus developers for guidance. Let's move to https://github.com/open-telemetry/opentelemetry-specification/issues/1891.

[jmacd]

See https://github.com/open-telemetry/opentelemetry-specification/issues/1891#issuecomment-1194348335