[mdatagen] allow filtering out metrics based on resource attributes

[povilasv]

Description:

This PR allows filtering out metrics based on resource attributes. For example:

        resource_attributes:                                                                      
          k8s.pod.name:
            enabled: true 
            exclude:
              #- strict: "kube-apiserver-kind-control-plane"
              - regexp: "kube-.*"
              - regexp: "coredns-.*"
              - strict: "coredns"
              - strict: "kindnet-mpb2p"

Would remove metrics that match regex or strict rules on resource attributes.

Link to tracking Issue:

open-telemetry/opentelemetry-collector-contrib#25134

Testing:

• Tested with k8scluster receiver in kind cluster.
• unit tests added
  Documentation:

[codecov]

Codecov Report

Attention: Patch coverage is 84.28571% with 11 lines in your changes are missing coverage. Please review.

Project coverage is 91.91%. Comparing base (0d62e4f) to head (d054b0e).

Files	Patch %	Lines
...plereceiver/internal/metadata/generated_metrics.go	75.60%	5 Missing and 5 partials ⚠️
filter/config.go	96.55%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9660      +/-   ##
==========================================
- Coverage   91.95%   91.91%   -0.04%     
==========================================
  Files         357      358       +1     
  Lines       16501    16571      +70     
==========================================
+ Hits        15173    15232      +59     
- Misses       1000     1006       +6     
- Partials      328      333       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dmitryax]

@povilasv can you please rebase? I finalized the mdatagen migration from the contrib repo

[povilasv]

@dmitryax rebased

[dmitryax]

@open-telemetry/collector-contrib-approvers, FIY: we are going to introduce another core module for this filtering functionality as discussed in open-telemetry/opentelemetry-collector-contrib#25161.

It has to be introduced as a public API in the core. I'm not sure what can be a better place other than filter. Any suggestions are welcome.

[andrzej-stencel]

Sounds like it's for defining the configuration, shouldn't it be something like config/configfilter?

If it's also for matching, then perhaps more like config/configmatch.

[povilasv]

It defines both configuration and the matching logic. We can split into two packages if needed, but currently it's really small package so I wouldn't 'bother 🤔

What about filter/filtermatcher?

In contrib we called following naming conventions:

• filter/filtermatcher
• filter/filterset
• filter/filterconfig

https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/internal/filter