-
Notifications
You must be signed in to change notification settings - Fork 41
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
bouncer metrics are adding significant load on OpenWrt router #377
Comments
@ne20002: Thanks for opening an issue, it is currently awaiting triage. In the meantime, you can:
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
Hello, We are reworking the way we collect metrics / add more metrics in this PR: #365 (the goal is to provide those metrics as well in We have optimized the way we collect metrics for both nftables (no more calls to the |
Hi @blotus |
Hello, I've just merged #365, and it should be released this week. There are some significant changes in how we collect metrics:
I'm going to close the issue, but feel free to reopen it if you still see huge CPU usage after the release. |
What happened?
When updating the bouncer to version 0.0.29-rc3 on my OpenWrt router (BananaPi R3) I realized that the bouncer is adding a significant load on the router when metrics are enabled. Usually the router has a very low load, it has a powerful processor.
The load added is by 10 - 20% on all 4 cpus only due to the metrics. This on a device usually at under 4%.
What did you expect to happen?
I'd like to not add additional load of this amount to the device when collecting metrics.
How can we reproduce it (as minimally and precisely as possible)?
Install OpenWrt on BPi R3 with luci-app-crowdsec-bouncer and enable metrics.
Anything else we need to know?
Most routers are devices with limited power but metrics are important. Before enabling the metrics in the bouncer the firewall rules already counted blocked packets and bytes. Thus it seems clear that the load must be caused by another value or the process of counting metrics itself.
I suggest to provide a setting for a limited number of metrics which should only include the number of dropped packets and bytes. None of the go internals is really necessary to know on normal operations.
The number of banned ips should be available on the lapi already. I don't know how this number is calculated and if it may be the cause of the load (counting the ips in the set?) but this should be tested and if the number of elements in the sets is not causing the load it may also be added to the limited set of metrics.
Also: it seems as if the metrics are continuously collected.
Maybe something like this may be a solution:
This would enable prometheus to collect only the needed metrics and would prevent unecessary load on the device. By chosing the interval on the callers side the load can also be reduced.
version
remediation component version:
crowdsec version
crowdsec version:
OS version
The text was updated successfully, but these errors were encountered: