Allow users to customize AttributesProcessor and append to exist View

[RuoqianXu]

Is your feature request related to a problem? Please describe.
I am a framework developer, and my framework integrates the opentelemetry sdk. In my case, I need to trim or perform additional processing on the attributes of all instrument metrics (to adapt to different observability systems). Although I can achieve attribute trimming by registering a View, if there are already existing views, I need to modify all of them. The io.opentelemetry.sdk.metrics.internal.view.AttributesProcessor can solve my problem. However, the current constructor of AttributesProcessor is not public, and the getAttributesProcessor method in the io.opentelemetry.sdk.metrics.View class and the addAttributesProcessor method in the io.opentelemetry.sdk.metrics.ViewBuilder are also not public. Currently, I can only use reflection for handling.

Describe the solution you'd like
Make AttributesProcessor, getAttributesProcessor, and addAttributesProcessor public. hopefully View can be mutable, it is not possible to directly append AttributesProcessor to an existing view now.

Describe alternatives you've considered
Maybe AttributesProcessor can be separated from View, can be registered in SdkMeterProviderBuilder. Similar to View, can use InstrumentSelector to select instrument metrics to apply AttributesProcessors.

[jack-berg]

Unfortunately, the AttributeProcessor concept is a hold over from an early metrics prototype which never made it into the specification, and we're bound by the spec for what feaatures we include as part of our public API.

Coincidentally, there is an active effort to extend the metrics SDK specification with a concept called "Measurement Processor", which is an extended version of the capabilities of AttributesProcessor: open-telemetry/opentelemetry-specification#4318

If that lands, we would implement a prototype in opentelemetry-java, and eventually stabilize the prototype when the feature is marked stable in the spec. The spec has a process for maturing features, which involves landing the feature as experimental, incubating for a while to gather feedback and wait for implementations, and eventually stabilize.

So unfortunately, we're blocked by the spec on this. And while there is active interest in the measurement processor concept (see all the support in this issue), its going to be some time before those APIs are available and stable in opentelemetry-java.

Have you considered a different option where you modify the attributes in custom MetricExporter implementation, before delegating to a downstream exporter? The downside of this is that export occurs asynchronously, so there's no ability to enrich attributes with context which is only available at the time the measurement takes place. But the upside is that its available today, so its a good option if you're not dependent on context.

[RuoqianXu]

Have you considered a different option where you modify the attributes in custom MetricExporter implementation, before delegating to a downstream exporter?

thanks for your reply and Suggestions.

I will try this way and also continue to pay attention to the "Measurement Processor" concept.