-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(rules): when naming rules files use clear namespace separation #6482
base: main
Are you sure you want to change the base?
Conversation
I see that these tests (https://github.com/prometheus-operator/prometheus-operator/actions/runs/8577200973/job/23509431752?pr=6482) failed - but I can't see how they relate to my change. Could they be flakey? |
I agree that it'd be useful to reverse-parse the rule's namespace/name but if we do this, it should be documented somewhere. We could also discuss what should be used to separate namespace and name. |
@simonpasquier This is 3 weeks old now - thoughts on what we can do here to move this along? |
I'm not 100% fan of the |
I don't really care what the separator is ... but I've just seen |
@simonpasquier i updated to use a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Description
Ref: #3468
I ran into the same issue that @janotav did with this comment. I want to be able to identify metrics from the Thanos Ruler around rule execution and failures and narrow them down to the
Namespace
andPrometheusRule
that they come from. The problem is the current naming pattern of$namespace-$rulename-$uid
doesn't account for resources that have-
's in the names... ie, the following rule creates a file namedmy-namespace-some-rule-thing-xxx-xxx-xxx-xxx-xxx
:The string
my-namespace-some-rule-thing-xxx-xxx-xxx-xxx-xxx
cannot be parsed through metric relabelings because you cannot definitively pull out thenamespace
andname
fields from the filename.Type of change
CHANGE
(fix or feature that would cause existing functionality to not work as expected)FEATURE
(non-breaking change which adds functionality)BUGFIX
(non-breaking change which fixes an issue)ENHANCEMENT
(non-breaking change which improves existing functionality)NONE
(if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)Verification
Due to #6284 - I was unable to fully test this locally.
Changelog entry
Please put a one-line changelog entry below. This will be copied to the changelog file during the release process.