Skip to content
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

Safely handle range vectors from prometheus api result #1636

Open
ta924 opened this issue Apr 29, 2024 · 2 comments
Open

Safely handle range vectors from prometheus api result #1636

ta924 opened this issue Apr 29, 2024 · 2 comments

Comments

@ta924
Copy link
Contributor

ta924 commented Apr 29, 2024

Describe the feature

Currently Flagger assumes that a successful api call to prometheus (which contains a result), will be able to access v.Value[1], which will result in a panic if the user configured a metric that returns a range vector. I understand that instant vectors must be used but that does make Flagger vulnerable. I would think a better option would be to evaluate if values were returned from the result and send an error the same as NaN or no values found.

Source: https://github.com/fluxcd/flagger/blob/main/pkg/metrics/providers/prometheus.go#L150

What problem are you trying to solve?

Better error handling

Proposed solution

Add Values in the prometheusResponse struct so it will be unmarshaled for evaluation. While iterating the Result of the api response, if Values are present return an error message without triggering a panic. I don't see any drawbacks to this solution outside of an additional failure scenario.

Any alternatives you've considered? No

Is there another way to solve this problem that isn't as good a solution?

The other option would be to evaluate if v.Value[1] is nil, if so return an error instead of a panic. It think it all comes down to how elaborate you want the failure message to be back to the user.

@aryan9600
Copy link
Member

yeah, this sounds good to me as well. are you interested in implementing the solution?

@ta924
Copy link
Contributor Author

ta924 commented Apr 30, 2024

@aryan9600 yes I will get a PR together for review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants