Verify compliant metric API specification implementation: Instrument Asynchronous Gauge

[MrAlias]

• Identify all the normative requirements, recommendations, and options the specification defines as comments to this issue
• Ensure the current metric API implementation is compliant with these normative requirements, recommendations, and options in those comments.

[MrAlias]

#3453

[MrAlias]

#3454

[MrAlias]

There MUST NOT be any API for creating an Asynchronous Gauge other than with a Meter.

With #3454 now complete, our implementation is compliant.

[MrAlias]

This MAY be called CreateObservableGauge. If strong type is desired, OpenTelemetry API] authors MAY decide the language idiomatic name(s), for example CreateUInt64ObservableGauge, CreateDoubleObservableGauge, CreateObservableGauge<UInt64>, CreateObservableGauge<double>.

We do not follow this optional criteria. We instead follow more common Go method naming and use Int64ObservableGauge and Float64ObservableGauge method names.

[MrAlias]

It is highly recommended that implementations use the name ObservableGauge (or any language idiomatic variation, e.g. observable_gauge) unless there is a strong reason not to do so.

I'm going to assume the authors intended "recommended" to be the normative key word "RECOMMENDED".

We do not follow this recommendation. #3453 is tracking this issue, and #3575 should address this.

[MrAlias]

For callback functions registered after an asynchronous instrument is created, the API is required to support a mechanism for unregistration.

I'm going to assume the authors intended "recommended" to be the normative key word "RECOMMENDED".

We are compliant with this, as explained here: #3373 (comment)

[MrAlias]

Remaining:

• Asynchronous Instrument API does not follow OTel Specification recommendation on naming #3453

[MrAlias]

Every normative clause from the Asynchronous Gauge section of the v1.16.0 specification has been identified and our API has been validated that it complies. Closing.