Implement Views API

[dyladan]

Views should be configurable through a MeterProvider

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#view

TODO: update description with requirements for views API

• Views should be able to select metrics using the following (all optional):
  • instrument type
  • instrument name (with wildcards)
  • meter name
  • meter version
  • schema url
• View name (optional - defaults to use instrument name)
• Configuration for view metric stream
  • Description
  • attribute keys
  • extra dimensions (from baggage/context)
  • Aggregation
  • exemplar reservoir factory or callback which allows different reservoirs to be chosen by the aggregation

[dyladan]

@legendecas I see you assigned yourself but I did a little of this already with the new SDK package frame. There is still a lot to do but I wanted to let you know.

[legendecas]

@dyladan Please go ahead. I was trying to bootstrap this but I found it will be easier if we have figured out how the internal data storage will be so I'm just started working on #2599. Remove assignments for now.

[legendecas]

The feature of extra dimensions is pending removal from v1.0: open-telemetry/opentelemetry-specification#2215

[dyladan]

@legendecas you've been pretty prolific in the metrics land so i wanted to ask if you were working on this or if you have a good idea of what still needs to be done here. I was going to work on this but want to make sure i'm not duplicating work.

[legendecas]

@dyladan I'm not currently focused on the views API. AFAICT, there are still some points left to do:

1. Renaming instruments with views and resolving name conflicts,
2. add the restriction to meet the spec statement: "the SDK MUST NOT allow Views with a specified name to be declared with instrument selectors that select by instrument type or wildcard."
3. Refining views public API for end users: currently the MeterProvider.addView have to be written as addView(new View(), /* optional */ new InstrumentSelector({ name: '*' }), /* optional */ new MeterSelector({ name: '*' )), which might (or might not) be promising as it is somewhat verbose.
4. Built-in dropping attributes AttributesProcessor: this is required in the spec for the configuration for the resulting metrics stream: "A list of attribute keys (optional). If provided, the attributes that are not in the list will be ignored"

[pichlermarc]

I'd like to help out with this one if @dyladan is okay with that. :)

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

[pichlermarc]

As far as I can tell the only thing missing for this to be done is exemplar reservoir support for views. I need to do some reading before I can pick up work on this, as I am not too familiar with it yet.

[dyladan]

Closing because views is implemented. Exemplars pushed to after GA. Opened a new issue for that.