Verify compliant metric SDK specification implementation: MetricExporter

[MrAlias]

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

[MadVikingGod]

Requirements from reading the Metric Exporter Section of the spec. This doesn't cover The Push or Pull Subsections as different tickets cover them.

• MetricExporter is an interface that can be implemented outside the SDK.

  MetricExporter defines the interface that protocol-specific exporters MUST implement so that they can be plugged into OpenTelemetry SDK and support sending of telemetry data.

• (Non-Normative) Metric Exporters always have an associated MetricReader.

  Metric Exporters always have an associated MetricReader.

• (Non-Normative) The SDK uses the aggregation and temporality properties of the Metric Exporters

  The aggregation and temporality properties used by the OpenTelemetry Metric SDK are determined when registering Metric Exporters through their associated MetricReader.

• (Optional) Automatic Configuration of metric Reader with an Exporter.

  OpenTelemetry language implementations MAY support automatically configuring the MetricReader to use for an Exporter.

• Metric Exporters must have a way to report an error condition

  Metric Exporters SHOULD report an error condition for data output by the MetricReader with unsupported Aggregation or Aggregation Temporality

• (Non-Normative) Multiple Exporters can be configured to on the same meter provider, using different MetricReaders.

  There could be multiple Push Metric Exporters or Pull Metric Exporters or even a mixture of both configured at the same time on a given MeterProvider using one MetricReader for each exporter.

Notes:
The actual Interface of the MetricExporter is defined in the Push Metric Exporter Section.
Non-Normative means that there is a description in the spec but does not include normative vocabulary indicating requirements to the spec.

[MadVikingGod]

• MetricExporter is an interface that can be implemented outside the SDK.
  • Done - Exporter
• Metric Exporters always have an associated MetricReader.
  • I don't think this is technically possible to enforce. To always have an associated Reader then they would the reader would have to be passed to the creation of the Exporter, but we do not control all constructors of Exporters (see above). This also would be inversion of the control flow, as Readers use Exporters, not the other way around.
  • A more generous interpretation is that the SDK will not use an Exporter except through a Reader, and we meet that requirement.
• The aggregation and temporality properties used by the OpenTelemetry Metric SDK are determined when registering Metric Exporters through their associated MetricReader.
  • The Aggregation and Temporality of a particular metric stream is somewhat complicated to determine, because it is a combination of the The View, and the Reader, and a default.
  • If the View does not set the Aggregation here, then the the stream will be check if the exporter sets an aggregation
  • Can a faulty Aggregation selector be passed to the Manual Reader?
    • This has been addressed in Add tests for malformed selectors in readers #4350
  • Can a faulty Aggregation selector be passed to the Exporter?
    • This has been addressed in Add tests for malformed selectors in readers #4350
• (Optional) Automatic Configuration of metric Reader with an Exporter.
  • We do not do this.
• Metric Exporters must have a way to report an error condition
  • Done - Export returns an error that can be used for this.
• Multiple Exporters can be configured to on the same meter provider, using different MetricReaders.
  • Done - Use of multiple WithReader options allows this.

The only task left open is the AggregationSelector and TemporalitySelector, to see if those can be abused.

[MrAlias]

Closing, done.