-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
promtail high CPU usage on default helm install #1102
Comments
Generated profile and trace files for So these CPU spikes are actually GC activity. I've tried to correlate these GC spikes with logs and looks like it's happening exactly when kubernetes discovery kicks in. We have quite a lot of pods in the cluster (total amount is about 8000, but only 2000 is running, others are in a I have validated this idea by limiting the namespaces to monitor. Removing the one with most of the pods solved the issue (but left me without logs for the crowded namespace). |
As a suggestion about how it can be fixed, I have following ideas:
|
@shuttie Thank you so much for all of this ! |
I was following along on slack and had some thoughts on this. Kubelet has many of these same problems, and there's been a lot of work to optimize it if I recall, but I'd suggest looking at how kubelet handles this. I believe field selectors do support node name when listing pods, but I believe the filtering on that is still happening in-memory on the API server, so I'm not sure how good that is, as it only reduces data transmitted, but could still be expensive for the API server, but it's also probably worth investigating. Since the metadata necessarily is is pretty limited, it might be available by querying the container runtime or parsing files for necessary info (namespace/pod-name) then only querying the single objects necessary (rather than doing a list/watch + filtering). This would probably mean more queries, but less overall information being fetched and then filtered. |
I back tracked the kubelet code to see where it sets up it's watchers and finally found it at: https://github.com/kubernetes/kubernetes/blob/67d928acdc351d3d4f9e20a92cee4452a26ed0c4////pkg/kubelet/config/apiserver.go#L33 It seems like it just uses a filtered watch using a field selector on the pod's spec.nodeName field matching the kubelet's nodeName. Seems like a relatively straight-forward change. In Upstream Prometheus that seems to be something that would be done here: https://github.com/prometheus/prometheus/blob/0fbc8c13a71d18c0d6c50b11d33f339954451d46/discovery/kubernetes/kubernetes.go#L271-L276 though I don't know what the best method of handling this change would be since it needs to be dealt with in upstream Prometheus. |
I think the best option is to open an issue on the Prometheus repo referencing this issue just to see if it would be acceptable. |
Describe the bug
I'm currently playing with promtail 0.3.0 on a medium-sized 50-node kubernetes cluster. And I'm observing a really high CPU usage of promtail pods even on a nodes with low amount of logs generated.
For example, there is a node with 3 pods running, emitting about 10kb of logs per second. Promtail has a constant high cpu usage pattern staying somewhere between 70-150% of CPU. Starting the promtail on this node with server.log_level=debug gives no hints about what this thing is doing: only lines regarding new targets registered once in a while.
Dumping goroutines multiple times shows that most of the running goroutines are spent somewhere in stages.Pipeline.Process. We also have a yet another promtail installation (non-k8s on AWS ElasticBeanstalk, so no helm) with much higher logging throughtput, maybe ~0.5Mb/s, and promtail is almost idle there. This hints me on some sort of performance issue with pipeline and relabeling, as helm chart's promtail config is quite heavy on label transformations.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Promtail should not constantly consume 100% of single CPU core.
Environment:
Screenshots, promtail config, or terminal output
Promtail logs example (nothing interesting here), with
server.log_level=debug
:goroutine dump 1:
goroutine dump 2:
dump 3:
dump 4:
dump 5:
The text was updated successfully, but these errors were encountered: