Update Metrics API to latest Feature-Freeze Spec

[pragmaticivan]

This issue tracks work needed to meet the API specification

General

• feat: Rename Labels to Attributes #2523
• feat(api-metrics): add schemaUrl to meter creations #2529
• Remove metric instrument bind/unbind #2545
• fix(sdk-metrics-base): remove metric kind BATCH_OBSERVER #2540

MeterProvider

• API method to register global
• API method to get global
• Verify API compliance of MeterProvider.getMeter #2546
• Metrics: configuration changes in MeterProvider and propagated to Meters #2547

Instruments

• Create or verify each instrument (creation method, interface, noop implementation)
  • [api-metrics]: Create or verify compliance of Counter #2548
  • [api-metrics]: Create or verify compliance of Async Counter #2550
  • [api-metrics]: Create or verify compliance of UpDownCounter #2549
  • [api-metrics]: Create or verify compliance of Async UpDownCounter #2551
  • [api-metrics]: Create or verify compliance of Histogram #2552
  • [api-metrics]: Create or verify compliance of Async Gauge #2553

[legendecas]

According to the tracking project https://github.com/orgs/open-telemetry/projects/8, implementations of Java and .net are expected to experiment with the new spec before the feature-freeze stage. And Metrics SDK spec is expected to reach feature-freeze at 9/30/2021.

[pragmaticivan]

Would that block development for experimental packages? This was also done in the go package 20 days ago: open-telemetry/opentelemetry-go#2202

Note in this PR:

Note: The OTel-Go metrics API is still considered experimental and subject to change in the future. We discussed making this change ASAP to avoid confusing new users who review the API specification and will not understand these legacy names.

[weyert]

I think the idea was to wait until the SDK spec is finalised based on experience last time were the spec changed quite a bit while working on developing it. Think this time it's decided to wait it's all set in stone before start working on it.

@pragmaticivan But you can always start making a list of difference between current implementation and the draft Metrics SDK :)

[vmarchaud]

Would that block development for experimental packages

Nothing, you are free to start working on it. As @weyert said we (contributors at the time) invested quit a bit of time to have a initial version at the time which was pretty much out of date as soon as the implementation was done so there was some kind of agreement on waiting stable spec before working on this.

[dyladan]

I am pretty sure the spec is settled enough to work on now.

[pirgeo]

These are a few requirements that I think need to be fulfilled in order to meet the specification. Note that these are only API requirements, the SDK changes should be tracked in a separate issue.

• feat(api-metrics): rename metric instruments to match feature-freeze API specification #2496
• Move from Label to Attribute*.
• Add a parameter to (optionally) specify schema_url on the MeterProvider.
• UpDownCounter uses BoundCounter under the hood, with BoundCounter specifying that it does not accept negative values. This should be consistent.

* Attributes can have numerical values and arrays of primitive data types as values (https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/common.md#attributes)

If there is something I missed, please let me know, and I'll extend the list.

[dyladan]

I moved the task list to the main issue up top. @pragmaticivan feel free to edit it as you see fit.

[pragmaticivan]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md is stable 🎉

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[dyladan]

@pragmaticivan all items are checked. Can this PR be closed?

/cc @legendecas

[pragmaticivan]

@dyladan LGTM!

[legendecas]

Closing for now. Thank you everyone for making this happen!