-
Notifications
You must be signed in to change notification settings - Fork 136
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
Recommendations are too low - maybe it does not properly use Prometheus for historic data? #399
Comments
@spewu thanks for the detailed report. We do use VPA directly from the recommendations block in the VPA object. I've commented on the other issue to try to get some clarification. |
The only thing I can think at the moment is that there's a bug in our chart that is not applying the flags to the VPA recommender correctly to connect to prometheus. Can you get the VPA recommender pod specification from your cluster, as well as check the logs on the recommender to verify that prometheus is being used? |
Thanks a lot for your quick reply, and sorry I have been so slow to get back to you! I am not 100% sure if this is what you are asking, but this is the specification for the VPA recommender running in our production cluster right now:
Here are the logs: |
I just restarted the VPA recommender to get the initialization logs output: |
I have managed to resolve the query by applying a configuration similar to what is outlined here:
which generates this query for historical data:
and when I run this query manually, I'm seeing results. However, this has not resulted in any appreciable difference in the recommendations made. |
Thanks for all the details of the journey! Looks like you got it working? |
Yep, it looks like it is working, although the |
Are you add extraArgs with address prometheus recommender pod ? How are you set extraArgs/prometheus/storage for goldilocks by use helm chart? |
@patsevanton these settings could be specified in the custom values.yaml file:
|
@spewu @bbetter173 Can you share your prometheus values.yaml used to scrape caadvisor metrics ? |
@blackhelicopters is you code support victoriametrics ? |
Which component are you using?: recommender - installed via https://charts.fairwinds.com/stable
What version of the component are you using?:
k8s.gcr.io/autoscaling/vpa-recommender:0.9.2
fairwinds-stable/vpa helm chart v. 0.4.4
Component version:
What k8s version are you using (
kubectl version
)?:kubectl version
OutputWhat environment is this in?:
Azure Kubernetes Service (AKS)
What did you expect to happen?:
I expected to see recommendations inside Goldilocks that would make more sense.
What happened instead?:
The current recommendations are very low for CPU, which would break the API if I followed them. So my current theory is that the VPA recommender is not reading the historic data properly.
How to reproduce it (as minimally and precisely as possible):
And this values file:
With this values file:
Anything else we need to know?:
My original
kube-prometheus-stack
values file looked like this:But I followed the advice on this answer on Stack Overflow to get the
job
label to saykubernetes-cadvisor
, and ended up with the values file listed higher up .... but this broke the Grafana dashboards, and it does not seem to have made any impact on the recommender either 🙁After getting help on this question on Stack Overflow the Grafana dashboards now work correctly, but the recommendations inside Goldilocks still seem way too low (for CPU at least).
Example:
If I were to follow that advice, the API would break, as it needs more CPU than 15m. In general, it seems like the recommendations in Goldilocks for CPU is always 15m - for all of our services. So something looks not right.
I initially posted this issue in the VPA repo, but they advised me to post it here instead, so 🤞
The text was updated successfully, but these errors were encountered: