Allow to unregister/stop/destroy metric instruments

[mateuszrzeszutek]

Is your feature request related to a problem? Please describe.
Currently there is no way to stop/remove an instrument after it is created (see open-telemetry/opentelemetry-specification#2232 for more details). This is a major difference when you compare OTel metrics API to Dropwizard or Micrometer, both of which allow removing instruments.

Describe the solution you'd like
For synchronous instruments we could just add a stop() (the name being whatever the spec decides) method to the interfaces representing each synchronous instrument.
Things get a bit more complicated with asynchronous instruments - right now buildWithCallback() methods return void, there's no object/concept in the API that would represent an already started async instrument. In case the spec issue is not resolved before metrics API going stable it will be pretty difficult to offer forward compatibility. How about we add initially empty interfaces for all async instruments and return them in buildWithCallback methods:

interface ObservableLongCounter {
}

// ...
interface LongCounterBuilder {
    ObservableLongCounter buildWithCallback(Consumer<ObservableLongMeasurement> callback);
}

Then we could just add methods to ObservableLongCounter in a forward-compatible manner once the spec issue is fixed.

Additional context
open-telemetry/opentelemetry-specification#2232
open-telemetry/opentelemetry-java-instrumentation#4919

[anuraaga]

@mateuszrzeszutek Thanks for bringing this up - it does seem to make sense to return an empty interface to give us flexibility to add this sort of feature and we need to do it before 1.10.0

[anuraaga]

For naming, somehow e.g., LongObservingCounter feels most natural to me but Observable would be fine too - it seems like a counter that is observing a long value.

[mateuszrzeszutek]

I just used the spec recommendation for the name

It is highly recommended that implementations use the name ObservableCounter (or any language idiomatic variation

LongObservingCounter is perfectly fine too; anything that mentions "observe" + instrument name will do.

[jkwatson]

We could add this later with an additional build method on the builders.

[anuraaga]

@jkwatson Could you describe your idea? Is it SyncThing build() and AsyncThing build(callback)? Since adding a return type for callback is compile compatible, but not ABI compatible, I think it's best to do it now with an empty interface, though it's still possible in the future for a differently named method.

[jkwatson]

Differently named method is what I was meaning.

[jkwatson]

Another option (just brainstorming here) would be to replace the Consumer<Observable*Measurement> with a custom interface which we could add to in the future to enable the SDK to call-back onto the registrant to provide hooks for deregistration. It would probably be a bit more convoluted, though (maybe that's ok if this is a rare bridge use-case, though?).

[jack-berg]

@mateuszrzeszutek now that #4143 is merged, do you want to keep this open? Technically, there's additional scope in this request that #4143 didn't solve since this requests a way to stop synchronous instruments.

[mateuszrzeszutek]

I think we can close this one - the most important issue has been resolved, and it looks like the discussion about stopping/deleting instruments/metric streams is being carried on in the spec repo. And it seems to be a more complex thing than just implementing a close() method.
Thanks!