Fix metrics collection in case of duplicate policy names #3006
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Despite the name, it's identical to TestingEnableAndReset and unused. Signed-off-by: Anna Kapuscinska <anna@isovalent.com>
lambdanis
added
kind/bug
lambdanis
force-pushed
the
pr/lambdanis/fix-policymetrics
branch
from
e95d6e4 to
5130118
Compare
kkourt
approved these changes
Oct 17, 2024
willfindlay
approved these changes
Oct 17, 2024
Add GetTestSensorManagerWithDummyPF function to testutils/sensors, that creates a dummy policy filter instead of using the global one. The only difference between dummy and disabled policy filter is that dummy doesn't return an error when adding/deleting a policy, so it allows to load a namespaced policy without maintaining the policy state. This can be useful to test functionalities that depend on the sensor manager but not on the policy filter state, e.g. policy metrics. Signed-off-by: Anna Kapuscinska <anna@isovalent.com>
This fixes a metrics collection error that was occurring in case there were multiple namespaced policies with the same name. The metrics collector is iterating over all policies and reports tetragon_tracingpolicy_kernel_memory_bytes metric for each of them. The metric used to be labeled only with the policy name, so in case there was a second policy with the same name, the collector reported a duplicate what causes the entire metrics collection job to fail. Adding a policy_namespace label should prevent duplicates. There is an underlying assumption that each policy returned by ListTracingPolicies has a unique (name, namespace) tuple - if it's not the case, then metrics collection might fail again. Also, I'm not sure if per-policy memory metrics should be reported for policies in states different than loaded. Currently they are - I didn't change that behaviour, but it's now covered by tests. Fixes: a5301b8 ("pkg/metrics: add metrics for policy kernel memory us") Signed-off-by: Anna Kapuscinska <anna@isovalent.com>
lambdanis
force-pushed
the
pr/lambdanis/fix-policymetrics
branch
from
5130118 to
10ed475
Compare
✅ Deploy Preview for tetragon ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
oh thanks a lot! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a metrics collection error that was occurring in case there were
multiple namespaced policies with the same name. The metrics collector is
iterating over all policies and reports tetragon_tracingpolicy_kernel_memory_bytes
metric for each of them. The metric used to be labeled only with the policy
name, so in case there was a second policy with the same name, the collector
reported a duplicate what causes the entire metrics collection job to fail.
Adding a policy_namespace label should prevent duplicates.
There is an underlying assumption that each policy returned by
ListTracingPolicies has a unique (name, namespace) tuple - if it's not the
case, then metrics collection might fail again. Also, I'm not sure if
per-policy memory metrics should be reported for policies in states different
than loaded. Currently they are - I didn't change that behaviour, but it's now
covered by tests.
Fixes: a5301b8 ("pkg/metrics: add metrics for policy kernel memory us")