Pablo Baeyens

cc @open-telemetry/collector-approvers @yurishkuro @mahadzaryab1 I am undecided on this. Questions for y'all: 1. Do you like this overall? (you can :+1: / :-1: this message, if :-1: it would be...

> > GetOrInsertDefault > > if this is only used for some form of e2e tests (surprising that it's needed) then perhaps it can be a static function named accordingly,...

Re-reading this I am not sure what the decision if any was. Do we want to have a separate mechanism for configuring inidividual metrics different from views or `service::telemetry::metrics`?

I feel like the [`disabled` parameter in the in-development `MeterConfig`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#meterconfig) would be the solution for this. This is not consistent with the rest of our configuration so I filed open-telemetry/opentelemetry-specification/issues/4344

@djaglowski So here is my proposal with some examples. The issue I linked above about `MeterConfig.disabled` could simplify this, but I am sticking with views config for all examples. My...

> Users who just want to drop one metric from the defaults will probably try to simply add a drop view for it. If they didn't have a level configured,...

> Concatenating the default list of views with a custom one by applying two configuration files will have the same confusing semantics as doing it automatically in the code, it...

@jade-guiton-dd This is how the `MeterConfig` would work (pending approval by the Configuration WG): https://github.com/open-telemetry/opentelemetry-configuration/pull/140. Could you make your proposal more concrete with some examples like I did on https://github.com/open-telemetry/opentelemetry-collector/issues/10769#issuecomment-2624984772...

I got that wrong too, sorry :/

Removed from Collector v1 project since this is what we agreed to do for it, will keep open to evaluate in the future whether we want to make `level` and...