feat: add new include_any filter policy for spanmetrics filter

[javiermolinar]

What this PR does:
This PR introduces a new filter policy type, include_any. This allows for a any span matching an include_any rule to be included.

This new filter policy is retrocompatible with the existing logic. So existing filters must work in the same way as today

The problem
The existing include policy is very rigid. Multiple include policies act as a logical AND. This means all conditions must be fulfilled for a span to be accepted. For example:

 filter_policies:
        - include:
            match_type: regex
            attributes:
              - key: resource.location
                value: eu-.*
         - include:
            match_type: strict
            attributes:
              - key: service.name
                value: foo

This configuration only matches spans where the service.name is "foo" and the resource.location starts with "eu". Any span failing either condition is dropped.

This makes certainscenarios impossible, such as filtering by span kind to reduce cardinality while wanting to include INTERNAL spans for a specific service:

 filter_policies:
        - include:
            match_type: regex
            attributes:
              - key: kind
              value: SPAN_KIND_(SERVER|CONSUMER)
         - include:
            match_type: strict
            attributes:
              - key: kind
                value: SPAN_KIND_(INTERNAL)
              - key: service.name
                value: foo

A span cannot be SERVER and INTERNAL at the same time, so this configuration would drop 100% of the spans.

The solution

The new include_any policy acts as a logical OR relative to other inclusion rules. If a span matches any include_any block, its accepted (as long as the exclude policy doesn't have a match).

 filter_policies:
        - include:
            match_type: regex
            attributes:
              - key: kind
              value: SPAN_KIND_(SERVER|CONSUMER)
         - include_any:
            match_type: stric
            attributes:
              - key: kind
                value: SPAN_KIND_(INTERNAL)
              - key: service.name
                value: foo
        - include_only:
            match_type: strict
            attributes:
              - key: kind
                value: SPAN_KIND_(CLIENT)
              - key: k8s.namespace.name
                value: bar

Under this logic, a span is included if it meets any of these criteria:

• kind is SERVER or CONSUMER
• kind is INTERNAL and service.name is foo
• kind is CLIENT and k8s.namespace.name is bar

Benchmarks

goos: darwin
goarch: arm64
pkg: github.com/grafana/tempo/pkg/spanfilter
cpu: Apple M3 Pro
                                         │ old_results.txt │          new_results.txt           │
                                         │     sec/op      │   sec/op     vs base               │
SpanFilter_applyFilterPolicyNone-11            4.010m ± 4%   3.887m ± 0%  -3.07% (p=0.000 n=10)
SpanFilter_applyFilterPolicySmall-11           50.03m ± 1%   48.00m ± 1%  -4.05% (p=0.000 n=10)
SpanFilter_applyFilterPolicyMedium-11          50.00m ± 1%   48.02m ± 1%  -3.97% (p=0.000 n=10)
SpanFilter_applyFilterPolicyRegex-11           50.12m ± 0%   47.98m ± 0%  -4.25% (p=0.000 n=10)
SpanFilter_applyFilterPolicyIntrinsic-11       21.62m ± 8%   21.77m ± 1%       ~ (p=0.436 n=10)
geomean                                        25.54m        24.79m       -2.95%

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[github-actions]

💻 Deploy preview available (feat: add new includeOnly filter policy for spanmetrics filter):

• https://deploy-preview-tempo-6392-zb444pucvq-vp.a.run.app/docs/tempo/next/

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7e38c162ab

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[carles-grafana]

I'm wondering if the include_only name is clear enough. Maybe include_any is better?

[electron0zero]

I'm wondering if the include_only name is clear enough. Maybe include_any is better?

+1, I think Include_any makes it more clear then include_only.

[github-actions]

💻 Deploy preview deleted (feat: add new include_any filter policy for spanmetrics filter).