Verify compliant metric API specification implementation: Instrument Asynchronous UpDownCounter

[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.

[jmacd]

See the discussion in #3278.

I'm concerned that the fix in #3350 will break when filters are applied. In the comment here (#3278 (comment)), there is a suggestion not to set() the aggregator to the last value, but to initialize the output aggregator to zero and then add() the result from each attribute set. That way when filters are applied, you get the sum not the last value.

I picked up on this because #3350 (review) should not be true -- that is counters should not be behaving exactly like gauges.

[MrAlias]

See the discussion in #3278.

I'm concerned that the fix in #3350 will break when filters are applied. In the comment here (#3278 (comment)), there is a suggestion not to set() the aggregator to the last value, but to initialize the output aggregator to zero and then add() the result from each attribute set. That way when filters are applied, you get the sum not the last value.

I picked up on this because #3350 (review) should not be true -- that is counters should not be behaving exactly like gauges.

This issues is about the compliance of the metric API, go.opentelemetry.io/ote/metric. This comment seems to be about the compliance of the SDK. Is there more to it? Is this meant to say our API implementation needs to be addressed?

[jmacd]

Sorry, I thought this was about end-to-end compliance testing. I'm not sure whether a new issue is needed for the comment in #3379 (comment), seems to fall in with #3278.

[MrAlias]

#3453

[MrAlias]

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

With #3454 now complete, our implementation is compliant.

[MrAlias]

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

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

[MrAlias]

It is highly recommended that implementations use the name ObservableUpDownCounter (or any language idiomatic variation, e.g. observable_updowncounter) 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 UpDownCounter section of the v1.16.0 specification has been identified and our API has been validated that it complies. Closing.