Implement spec: MetricFilter

[asafm]

Describe the solution you'd like
Implement the following 3 features, as shown in compliance metric:

• A metric Producer accepts an optional metric Filter
• The metric Reader implementation supports registering metric Filter and passing them its registered metric Producers
• The metric SDK's metric Producer implementations uses the metric Filter

Additional context
The metric filter specifications PR: open-telemetry/opentelemetry-specification#3566

Plan

• Implement MetricFilter
• Fix OpenCensusMetricProducer to implement with MetricFilter and not use default implementation

[asafm]

@jack-berg I'm starting to implement this

[saxocellphone]

Hi are there any updates for this issue? I have an use case for it. I can also take over implementation if needed.

[jack-berg]

Are you sure you need it? Its a pretty complicated feature that seems to make sense when 1. you have a huge number of distinct series such that reading the aggregated state of all is too expensive. 2. you're implementing you're own pull-based metric reader, which somehow includes the filter as an input (i.e. query parameter).

The memory churn associated with reading aggregated state of many series is significantly lower these days thanks to the reusable_data memory_mode concept.

[saxocellphone]

Our usecase is unconventional in that third-parties will be exporting metrics to us, and we will be providing them with a way to filter out metrics they don't want to be sending. The alternative would be writing our own reader, but this way seems cleaner.

[jack-berg]

The alternative would be writing our own reader, but this way seems cleaner.

To make use of MetricFilter, you'd need to write your own reader:

• A metric Producer accepts an optional metric Filter
• The metric Reader implementation supports registering metric Filter and passing them its registered metric Producers

---

Our usecase is unconventional in that third-parties will be exporting metrics to us, and we will be providing them with a way to filter out metrics they don't want to be sending.

So you want to provide a way for these third-parties to configure which metrics are exported?

You can do this today with views. Problem with views is that they are global, so if the third-party wants the metric and just doesn't want to send it to you, views won't be useful. An alternative is to have the third parties wrap their exporters with InterceptableMetricExporter, and have them configure a predicate dictating which metrics are exported.

[saxocellphone]

You can do this today with views. Problem with views is that they are global, so if the third-party wants the metric and just doesn't want to send it to you, views won't be useful. An alternative is to have the third parties wrap their exporters with InterceptableMetricExporter, and have them configure a predicate dictating which metrics are exported.

Didn't know about the interceptors! That should work for our use case. Thanks for recommending