Add numeric operators for filters.

[pilhuhn]

Addresses #1291

This introduces new numeric filter options

• equals
• not_equals
• greater_than
• greater_equals
• less_than
• less_equals

To be used e.g. like the following:

filter:
  application:
    server.port:
      equals: 8787

[codecov]

Codecov Report

❌ Patch coverage is 62.71186% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.58%. Comparing base (7475bff) to head (b671371).
⚠️ Report is 26 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/filter/attribute.go	50.00%	11 Missing and 2 partials ⚠️
pkg/filter/matcher.go	72.72%	9 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1323      +/-   ##
==========================================
+ Coverage   43.51%   43.58%   +0.06%     
==========================================
  Files         305      307       +2     
  Lines       32864    32945      +81     
==========================================
+ Hits        14301    14359      +58     
- Misses      17643    17665      +22     
- Partials      920      921       +1     

Flag	Coverage Δ
integration-test	21.71% <0.00%> (+0.22%)	⬆️
integration-test-arm	0.00% <0.00%> (ø)
integration-test-vm-x86_64-5.15.152	?
integration-test-vm-x86_64-6.10.6	?
k8s-integration-test	2.35% <0.00%> (-0.01%)	⬇️
oats-test	0.00% <0.00%> (ø)
unittests	44.40% <90.24%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[grcevski]

What do you think about using *float64 instead of float64? In that case we can tell if the option is not set and allow us to filter on 0. We often have cases where maybe by error we cannot capture the http.code and we write 0, so I can see folks wanting to set a filter on that.

[grcevski]

I think we need to add some statement that checks if none of these are set and report an error.

[grcevski]

What do you think about making these *float64? Like this

GreaterThan   *float64 `yaml:"greater_than,omitempty"`

That way we can test for the 0 port, 0 status code etc. Sometimes bugs in the eBPF code prevent us from finding the correct connection information so folks can filter on 0 server port etc.

[grcevski]

Actually I also wonder if we can make them ints? Technically, eBPF doesn't support floating point operations, it's not in the instruction set, so we can never get float value from there.

[pilhuhn]

I was originally thinking about floats for timings. On a closer look after your comment, I see that timings are either a float as string ("1.2ms") or int in µs, so we should be good here.

[pilhuhn]

@grcevski -Is there any other place where this should be tested -- e.g. via config.yaml files?-
Actually I could add a config.yml in internal/test/integration/configs but I am a bit hesitant, as the i-tests depend on Docker (see #1301)

[pilhuhn]

Btw: how are docs updated then? They live in https://github.com/open-telemetry/opentelemetry.io/tree/main/content/en/docs/zero-code/obi - right? How is that then synced with the OBI releases?

[mariomac]

@pilhuhn I don't think there is yet any synchronization mechanism with the releases (we are still in a pre-1.0 status) You can just update there the documents

[grcevski]

LGTM! This looks great now! I think the unit testing is sufficient, since we already have other test filters.