-
Notifications
You must be signed in to change notification settings - Fork 99
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: enable multiple label values #115
feat: enable multiple label values #115
Conversation
53e7eeb
to
5fbd088
Compare
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.
you'd need a rebase :)
7e7980d
to
4e21823
Compare
injectproxy/routes.go
Outdated
if r.labelValue != "" && formValue != "" { | ||
err := req.ParseForm() | ||
if err != nil { | ||
return "", fmt.Errorf("the query parameter can not be parsed. %s", err.Error()) |
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.
return "", fmt.Errorf("the query parameter can not be parsed. %s", err.Error()) | |
return "", fmt.Errorf("the query parameter can not be parsed: %w", err) |
6387f2e
to
47020f0
Compare
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.
I realize that there's more work needed: while the PR works the /api/v1/query and /api/v1/query_range endpoints, it would break other endpoints such as /federate, /api/v1/rules, /api/v2/silences, ...
I think that enforceLabel()
needs to store the slice of label values in the context. Then each downstream handler does whatever it needs with it.
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 a lot for the effort! It's definitely more involved than initially envisioned 😅
I'm still not decided on the best way to deal with the silences endpoint, i'll need to think about it 🤔
injectproxy/silences.go
Outdated
modified := models.Matchers{ | ||
&models.Matcher{Name: &(r.label), Value: &lvalue, IsRegex: &falsy}, | ||
&models.Matcher{Name: &(r.label), Value: &matcherValue, IsRegex: &truthy}, | ||
} | ||
for _, m := range sil.Matchers { | ||
if m.Name != nil && *m.Name == r.label { |
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.
if the enforced label is namespace=~"ns1|ns2"
and someone creates a silence with namespace="ns1"
then namespace="ns1"
will be dropped which is not the desired outcome because you may want to narrow down the silence.
I think that we need to keep all input matchers and append the enforced matcher unconditionally? It would also simplify the delete endpoint since the only check would be to verify that the deleted silence contains a namespace=~"ns1|ns2"
matcher (given example above).
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.
I have updated the code.
If the enforced label is namespace=~"ns1"
, and someone creates a silence with namespace="ns1"
, then both matchers will be added:
[
"namespace=~\"ns1\"",
"namespace=\"ns1\""
]
For List, Update and Delete, only silences exactly contain a namespace=~"ns1"
will be processed.
Did I understand you correctly?
I resolved some conversations to make this thread(pull request) easier to read and follow. Please tell me if I'd better not to resolve them. @simonpasquier |
Wow, it would be great to have this merged soon! |
Nice useful feature, is there any plan to merge this soon? |
@simonpasquier can we expect that this gets merged anytime soon or are there any open issues you see? |
+1 |
@simonpasquier doesn't seem to have had time to review this PR further. Would maybe someone else from the maintainers have time to take a look here? @squat @brancz |
hey! Sorry for the lag on this PR. I'm putting it at the top of my review list as I'm aware that there's high demand. |
@Kirchen99 now that #118 is merged, you'd have to rebase and resolve conflicts. Sorry about that but once it's done, I'll review the PR :) |
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <latias_latios@126.com>
Signed-off-by: Kirchen99 <9981745+Kirchen99@users.noreply.github.com>
c2083a3
to
8472eba
Compare
👋 I'm taking a look at it right now. Since the silences API is problematic with multiple label values, I'd be in favor of declaring that the proxy doesn't support silences in this mode of operations. The main use case of multi-labels is for the Prometheus API anyway so not supporting the Alertmanager API isn't a blocker IMHO. I'm going to push some commits on top of your PR to implement this. |
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
When the original filter query parameter already includes the enforced label, the proxy should preserve it as it indicates that the user wants to filter down the list of silences/alerts. Signed-off-by: Simon Pasquier <spasquie@redhat.com>
When prom-label-proxy is configured with multiple label values, it should preserve the existing matchers because users actually want to return results for a subset of the metrics. In practice when configured with `namespace=~"bar|foo"`, the query `up{namespace="foo"}` is translated into `up{namespace="foo",namespace=~"bar|foo"}` instead of `{namespace=~"bar|foo"}`. This change is similar to 26b0a61 but for the Prometheus API endpoints. Signed-off-by: Simon Pasquier <spasquie@redhat.com>
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
661cf19
to
3847271
Compare
@Kirchen99 I've added a couple of commits on top of your work. The main changes are
Regarding the last 2 points, I don't remember if we already discussed it in this PR but IMHO this is what makes most sense compared to dropping the existing matcher unilaterally. My changes are https://github.com/prometheus-community/prom-label-proxy/pull/115/files/8472eba307611d1f2cf9181e70e3319ecbb90976..4882a18523e612324514b1f5ff8c7f8c465e71cc. Happy to hear your feedback. |
@simonpasquier Thank you for your commits and the detailed explanation of the changes. I like your Idea on the last 2 points and really appreciate your work and the improvements you've made. The changes look good to me, and I'm excited to see them being merged. |
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 again @Kirchen99 for your tenacity 🎉 and sorry it took so long to review... |
Signed-off-by: Kirchen99 latias_latios@126.com
Solves the issue: #27
Example:
Run prom-label-proxy with following args:
Try to get something with
curl
:See the result: