Verify compliant metric API specification implementation: MeterProvider

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

From the v1.16.0 version of the metric API specificaiton:

Normally, the MeterProvider is expected to be accessed from a central place.
Thus, the API SHOULD provide a way to set/register and access a global default
MeterProvider.

This is provided in the global package currently. The plan is to export a top-level function in otel that wraps the ones in global once it is a stable package.

[MrAlias]

Notwithstanding any global MeterProvider, some applications may want to or have to use multiple MeterProvider instances, e.g. to have different
configuration for each, or because its easier with dependency injection
frameworks. Thus, implementations of MeterProvider SHOULD allow creating an arbitrary number of MeterProvider instances.

Though this is the API specification, this recommendation is talking about our implementation in the SDK. For what it is worth, our implementation does allow for direct creation of MeterProviders with the NewMeterProvider function.

[MrAlias]

The MeterProvider MUST provide the following functions:

• Get a Meter

The MeterProvider interface is defined this way.

[MrAlias]

This API MUST accept the following parameters:

• name (required):

As shown in the previous comment, the Meter method of a MeterProvider is required to accept a name parameter we call instrumentationName in the API.

This name SHOULD uniquely identify the instrumentation scope, such as the instrumentation library (e.g. io.opentelemetry.contrib.mongodb), package, module or class name. If an application or library has built-in OpenTelemetry instrumentation, both Instrumented library and Instrumentation library may refer to the same library. In that scenario, the name denotes a module name or component name within that library or application.

This recommendation, while it exists in the API specification is not relevant to the API. It is for users of the API instead.

In case an invalid name (null or empty string) is specified, a working Meter implementation MUST be returned as a fallback rather than returning null or throwing an exception, its name property SHOULD keep the original invalid value, and a message reporting that the specified value is invalid SHOULD be logged. A library, implementing the OpenTelemetry API may also ignore this name and return a default instance for all calls, if it does not support "named" functionality (e.g. an implementation which is not even observability-related). A MeterProvider could also return a no-op Meter here if application owners configure the SDK to suppress telemetry produced by this library.

This requirement is again for implementations of the API, not the API.

• version (optional): Specifies the version of the instrumentation scope if the scope has a version (e.g. a library version). Example value: 1.0.0.

WithInstrumentationVersion is used to return an option that is passed to the Meter method to configure this.

• [since 1.4.0] schema_url (optional): Specifies the Schema URL that should be recorded in the emitted telemetry.

WithSchemaURL is used to return an option that is passed to the Meter method to configure this.

• [since 1.13.0] attributes (optional): Specifies the instrumentation scope attributes to associate with emitted telemetry.

The current API does not support this optional feature. The design of the API does allow for an option to be added at a later time that will support this configuration though.

[MrAlias]

Meters are identified by name, version, and schema_url fields. When more than one Meter of the same name, version, and schema_url is created, it is unspecified whether or under which conditions the same or different Meter instances are returned. It is a user error to create Meters with different attributes but the same identity.

The term identical applied to Meters describes instances where all identifying fields are equal. The term distinct applied to Meters describes instances where at least one identifying field has a different value.

Implementations MUST NOT require users to repeatedly obtain a Meter with the same identity to pick up configuration changes. This can be achieved either by allowing to work with an outdated configuration or by ensuring that new configuration applies also to previously returned Meters.

Note: This could, for example, be implemented by storing any mutable configuration in the MeterProvider and having Meter implementation objects have a reference to the MeterProvider from which they were obtained. If configuration must be stored per-meter (such as disabling a certain meter), the meter could, for example, do a look-up with its identity in a map in the MeterProvider, or the MeterProvider could maintain a registry of all returned Meters and actively update their configuration if it changes.

The effect of associating a Schema URL with a Meter MUST be that the telemetry emitted using the Meter will be associated with the Schema URL, provided that the emitted data format is capable of representing such association.

Again, this all recommends or requires things of the API implementation not the API itself. Given it does not apply to the API its not relevant to validate here.

[MrAlias]

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