Support for asynchronous Histogram instrument

[jmacd]

What are you trying to achieve?

I was looking to update the https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation/runtime Golang runtime metrics package to use the runtime/metrics package introduced in Go-1.16. This package exposes official Go runtime metrics names, gives units and value types and type information needed to translate into OTel's metric data model. The fit is very good, except there are 3 (ordinary) histograms and 1 gauge histogram.

The access method for these metrics use an asynchronous interface. It is impossible for an asynchronous instrument to report a histogram, presently. In an earlier version of the OTel specification, I had proposed that we allow the use of synchronous instruments from asynchronous callbacks--which helped with this problem in the past--but that wouldn't help in the current specification, since each Reader executes callbacks independently, it is now incorrect to allow use of synchronous instruments from asynchronous callbacks.

Adding an asynchronous Histogram instrument would allow (in this case) an efficient transfer of metric data from the Go runtime to the OT. Without such a mechanism, it is really difficult to report this data from a callback. We would need to use a goroutine and synchronous instruments to report these histograms.

What did you expect to see?

The histogram is pre-calculated, meaning the callback receives slices of buckets and counts. Although it would require a lot of new API surface, it would be natural to support an API like Observe(histogram_value) for an asynchronous histogram instrument. It is conceptually challenging to try to report a histogram, otherwise, from an asynchronous callback.

Additional context.

See #607, where the issue of how to report async histogram observations was discussed previously.

[pirgeo]

This would only work for explicit-bucket histograms, right? If you want to transfer it via an exponential histogram, there is no way of converting the information into an exponential histogram without substantial loss of information, or am I missing something?

[reyang]

This would only work for explicit-bucket histograms, right? If you want to transfer it via an exponential histogram, there is no way of converting the information into an exponential histogram without substantial loss of information, or am I missing something?

I feel this is slightly different from what Instrument is designed for, it seems a better fit for MetricReader (e.g. how OpenTelemetry Java bridges Micrometer with the OpenTelemetry SDK).