BatchObserver semantics and usage patterns need clarification

[jkwatson]

What are you trying to achieve?

The specification for the required behavior of BatchObserver and associated instruments is currently underspecified. See this PR attempt at clarification for additional context: #1030 .

In particular, we need to make it clear that Observer instruments that are created via a BatchObserver can only have callbacks that are handled by that BatchObserver, and no other callback can be associated with them. This may end up changing the semantics of the BatchObserver itself, and the patterns for instrumentation creation that it exposes.

[jkwatson]

@thisthat would you be willing to collaborate on writing the spec update for this, since you've been working on the Java implementation?

[thisthat]

@jkwatson I am down to collaborate on the spec. However, I don't feel confident driving it because I just start to look into the metric part of OTel.

[jkwatson]

@jkwatson I am down to collaborate on the spec. However, I don't feel confident driving it because I just start to look into the metric part of OTel.

ok, I'll try to write something up, and I'll tag you on the PR

[kenfinnigan]

@jkwatson I've been spending some time looking at this and the related issues/PRs today and I had a couple of comments.

Batch Observer in the spec is confusing from looking at the example as it doesn't appear it would even "compile" as it's referencing the observers inside the callback before they're even created.

It makes me wonder whether the Batch observer shouldn't have the ability to create observers and only associate them, as to me it appears to be a "chicken and egg" type problem.

I think I saw it mentioned by @jmacd in another issue, that it would be good to have a .start() on the Batch observer after which point no more meter associations can be made.

Happy to help with spec clarification, but wanting to make sure I'm understanding the problem first

[jkwatson]

I think the goal is to make sure that only one callback is registered per instrument. I think this is also an issue with the standard Observers, honestly.

One approach, I think, is to not leak the instruments out of the creation flow at all, so that no references to instruments are exposed once they have been created and a callback has been registered. I don't know if there are use-cases that would be extra difficult to implement if we did that, though.

[jkwatson]

I'm going to un-assign this from me, since I am not spending any time on it.

[reyang]

As we're releasing the Metrics API as stable #2104 (which doesn't have BatchObserver), closing this issue.