Should the in-memory exporter be a pull metric exporter?

[alanwest]

Currently, the spec considers the in-memory exporter a push metric exporter:

In-memory Metrics Exporter is a Push Metric Exporter which accumulates metrics data in the local memory and allows to inspect it (useful for e.g. unit tests).

The original intent of #2415 was to define a default interval to push metrics from a periodic metric reader paired with the in-memory exporter. The interval I proposed was infinite - that is, by default, an explicit force flush would be required to collect metrics. This raised the question of whether the in-memory exporter is actually a pull metric exporter.

An argument was offered in favor of leaving it as a push exporter #2415 (comment).

A number of folks felt that providing it as pull metric exporter offers better ergonomics for the primary use case which is unit tests. One suggestion (#2415 (comment)) is that both push and pull may be valuable.

[aabmass]

I like the suggestion that we don't specify if its push or pull which @alanwest mentioned.

[alanwest]

I like the suggestion that we don't specify if its push or pull which @alanwest mentioned.

I was taking this a step further and questioning whether we can just remove the entire in-memory exporter specification.

In contrast, I see value in the stdout exporter specification since it's pretty common for end users to pick it up when experimenting with the OTel SDKs. It makes sense to me that it has some semblance of uniform usage/behavior from language to language.

I'm uncertain if striving for uniformity should also be a requirement for the in-memory exporter as I'm unfamiliar with any scenarios where end users are using it.

[ocelotl]

I was taking this a step further and questioning whether we can just remove the entire in-memory exporter specification.

Yes, I agree. The spec should not be concerned with debugging or testing tools. Both of them can be very language specific:

• In the case of debugging, what this exporter can do, a debugger can do as well in many cases.
• In the case of testing, what this exporter can do, a mock can do as well in many cases.

If this is still something that others consider should be part of the spec, at least make this optional.