api/rules: Add filtering on rule name/group/file #7560
Conversation
jacobbaungard
force-pushed
the
rulefilters
branch
from
bdd78a9
to
66ba37e
Compare
This commits adds the option of filtering rules by rule name, rule group, or file. This brings the rule API closer in-line with the current Prometheus api. Signed-off-by: Jacob Baungard Hansen <jacobbaungard@redhat.com>
jacobbaungard
force-pushed
the
rulefilters
branch
from
66ba37e
to
6ce555d
Compare
| } | ||
|
|
||
| // filterRulesbyMatchers filters rules in a group according to given matcherSets. | ||
| func filterRulesByMatchers(ruleGroups []*rulespb.RuleGroup, matcherSets [][]*labels.Matcher) []*rulespb.RuleGroup { |
There was a problem hiding this comment.
I think we also need to update this function now to better mimic prometheus/prometheus#10194?
There was a problem hiding this comment.
Yes, most likely. We also need exclude_alerts to be fully aligned with the Prometheus API. Could we deal with those in separate PRs perhaps?
| rnSet := queryFormToSet(ruleName) | ||
| rgSet := queryFormToSet(ruleGroup) | ||
| fSet := queryFormToSet(file) |
There was a problem hiding this comment.
Do you think just using slices.Contains instead of set might be more memory intensive?
There was a problem hiding this comment.
The reason I did it like this, was simply because that's how the code looks like in Prometheus. I am not sure if there are significant performance benefits either way, although perhaps the code is a bit cleaner using slices.Contains, so happy to change to that approach if you think it's best?
There was a problem hiding this comment.
Ah I see, fine if it mirrors prometheus then
This commits adds the option of filtering rules by rule name, rule group, or file. This brings the rule API closer in-line with the current Prometheus api. Signed-off-by: Jacob Baungard Hansen <jacobbaungard@redhat.com>
Changes
rule_name,rule_grouporfile. This brings the rules api closer in-line with Prometheus.Verification