NETOBSERV-1352 enhance prom filters for RTT metrics

[jpinsonneau]

This PR improve prom metrics filtering introducing:

• !nil to match presenceof the field with any value
• nil to match absence of the field
• | splitter to match at least one value

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (914d470) 66.03% compared to head (2f040d3) 67.07%.
Report is 22 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #478      +/-   ##
==========================================
+ Coverage   66.03%   67.07%   +1.04%     
==========================================
  Files          94       94              
  Lines        6921     6724     -197     
==========================================
- Hits         4570     4510      -60     
+ Misses       2092     1948     -144     
- Partials      259      266       +7     

Flag	Coverage Δ
unittests	67.07% <82.35%> (+1.04%)	⬆️

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

Files	Coverage Δ
pkg/api/encode_prom.go	100.00% <ø> (ø)
pkg/confgen/flowlogs2metrics_config.go	68.83% <100.00%> (ø)
pkg/pipeline/encode/encode_prom.go	77.35% <81.25%> (-0.68%)	⬇️

... and 19 files with indirect coverage changes

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

[jotak]

LGTM

[github-actions]

New image:
quay.io/netobserv/flowlogs-pipeline:555ba5d

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=555ba5d make set-flp-image

[jotak]

@jpinsonneau I flagged LGTM, but taken in the light of bug https://issues.redhat.com/browse/NETOBSERV-1344, we will need to have filters such as "FlowDirection==1 OR FlowDirection==2" and/or "FlowDirection!=0" and/or "FlowDirection~=1|2" ... we should probably think about that before merging

[jpinsonneau]

@jpinsonneau I flagged LGTM, but taken in the light of bug https://issues.redhat.com/browse/NETOBSERV-1344, we will need to have filters such as "FlowDirection==1 OR FlowDirection==2" and/or "FlowDirection!=0" and/or "FlowDirection~=1|2" ... we should probably think about that before merging

Let's just merge all metrics PRs pending before doing the fix everywhere so we don't miss any ?

[github-actions]

New image:
quay.io/netobserv/flowlogs-pipeline:e54bae8

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=e54bae8 make set-flp-image

[jotak]

I'm ok to go with it but just to mention a small concern, it creates some reserved words or characters that are not possible to have in filters as raw text .. even if today it sounds unlikely to have "nil" or "|" actually written in a field and to be willing to filter on that (as a text value), still we are creating reserved keyword that we could avoid by just changing the API.

E.g: as an alternative, we could implement a type param on filters, as an enum: exact (= current behaviour), presence, absence, regex.
wdyt? we could do that as a follow-up

[jpinsonneau]

I'm ok to go with it but just to mention a small concern, it creates some reserved words or characters that are not possible to have in filters as raw text .. even if today it sounds unlikely to have "nil" or "|" actually written in a field and to be willing to filter on that (as a text value), still we are creating reserved keyword that we could avoid by just changing the API.

E.g: as an alternative, we could implement a type param on filters, as an enum: exact (= current behaviour), presence, absence, regex. wdyt? we could do that as a follow-up

As you prefer. I don't have strong opinion on that. Feel free to merge if it's blocking other PRs else I can refactor here; just let me know.

[jotak]

/lgtm
I found another reason to enhance the prom API: we need a way to scale up/down the value stored in metrics. We need that for the RTT metric , which currently is expressed as nano-seconds, which isn't convenient when read in dashboards. So, there will be a follow-up

[jotak]

/approve
(this is blocking other PRs)

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jotak

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jotak]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment