Spatial aggregation for async instruments with filtering views

[fandreuz]

Fixes #4901

I propose the following changes:

• AsynchronousMetricStorage now declares void record(Attributes, long) and void record(Attributes, double) instead of a single void record(Measurement), to enable using AggregatorHandle within the class.
• AsynchronousMetricStorage now contains two long fields (startEpochNanos, epochNanos) which are injected before running the callbacks, as an alternative to passing a Measurement object.
• Some tests had to change due to the change in the interface of AsynchronousMetricStorage

[linux-foundation-easycla]

• ❌ - login: @fandreuz / name: Francesco Andreuzzi . The commit (ab8bd4d, 0c63775, e942dc2, ed783f9, 6816f91) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[fandreuz]

I'd like to discuss the test here. I would expect a cumulative sum instrument to aggregate all occurrences with empty attributes. Thus, I would expect to see 6 here instead of 3.

To preserve this behavior, I clear the values for all the attributes at every collection, which is why AsynchronousMetricStorageTest#collect_reusableData_reusedObjectsAreReturnedOnSecondCall is failing. I'd like to clarify this aspect before fixing it.

[jack-berg]

I'd like to discuss the test here. I would expect a cumulative sum instrument to aggregate all occurrences with empty attributes. Thus, I would expect to see 6 here instead of 3.

Yes I believe you're correct. The test / logic seem appear to be incorrect currently

Oh I forgot about a fundamental detail of asynchronous instruments: conceptually, when you make an observation with a cumulative instrument, we say that you are observing a cumulative value. Thus, if we have a reader with cumulative temporality which reads twice and invokes the callbacks twice, and the callback records the same value 3 each time, the reported value should indeed be 3 and not 6.

Consider it from the perspective of this instrumentation which records information about classes loaded. If in sequential reads the callback records that 100 classes have been loaded, the output of a cumulative reader should always be 100, not N*100 (where N is the number of times the callback has been invoked). Instrumentation is not responsible for managing state and recording only the delta.

[jack-berg]

Thanks for working on this. This is pretty complex code when you consider the combinations of cumulative + delta, reusable + immutable data mode, and our desire to maintain zero memory allocations with reusable data mode after the application reaches steady state.

So reviews need to be slow / careful, but I am definitely interested in getting this issue resolved!

[jack-berg]

Can we combine these into a single operation?

[jack-berg]

I don't think this log message makes sense anymore: Previously we knew that that the instrument itself had recorded multiple values for the same attributes. Now we have know way of telling whether it was the instrumentation that recorded the same attributes, or that the attributes were the same after applying the view attribute filter.

We could continue this logging by maintaining state that tracks the unique original unfiltered attributes recorded, but that seems too expensive.

[jack-berg]

It looks like you've replaced the reused points hash map with a local variable Map<Attributes, T> currentPoints = new HashMap<>(); in the collect method.

We've got to reuse resources to continue to achieve our goal not allocating any additional memory once the SDK reaches steady state. Details available here: https://opentelemetry.io/blog/2024/java-metric-systems-compared/#opentelemetry-java-metrics

[jack-berg]

Let's retain the asserts to verify the epoch informatinon was set. Applies to other tests as well.

Suggested change

	verify(mockAsyncStorage1).record(Attributes.empty(), 5);
	verify(mockAsyncStorage1).setEpochInformation(0, 10);
	verify(mockAsyncStorage1).record(Attributes.empty(), 5);