Allow to omit default attributes per Meter/Instrument

[nicoschaefe]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

Our Context
We have multiple Nodejs services using shared libraries including one shared library that provides some code around the actual OTEL libraries for configuration and convenience.

Our Use Case
We want to centrally define a set of default attributes per service pod which are set for all Meters/Instruments if not specified differently (e.g. landscape, service, pod index). There are exceptions where we want to omit some of the default attributes for a Meter/Instrument - especially because there are dimension/attribute limits on our telemetry backend and we need to avoid unnecessary dimensions where possible.

Example
We have an attribute instanceIndex that relates to the service pod index. This is a common property relevant for many Meters/Instruments that we use. However, when there is no use case to group data by instanceIndex later on, we do not need to submit this attribute for specific Meters/Instruments. The cardinality of this attribute scales with the amount of pods. So we would like to omit this property where its not needed.

What we do today
Today we pass the default attributes as a resource object to the MeterProvider. Omitting some attributes in exceptional cases for some Meters/Instruments is not supported.

Discarded Ideas

• One option could be to omit the attributes in the resource object that we pass to MeterProvider and then on demand pass them in when using "add", "record", "observe". However, we have 100s such code places scattered across libraries. We do not want to maintain attributes at all these places. Also when adding another similar attribute we would again need to add it to all places except a few.
• Another option could be "Views" that can be provided to the MeterProvider. However, they can only be used for attributes provided by individual measurements, not for resources passed to the MeterProvider.
• A second MeterProvider. This would come with a second MetricReader and MetricExporter. This causes additional connections to the backend and overhead.

Solution Ideas

• Extend the View concept to support resource attributes
• Allow to overwrite resource attributes via Instrument.add/record/observe
• Accept a resource parameter for getMeter() to set and replace the default resource attributes.
• Are there other existing features we are not aware of that can solve our problem?