fix(feeder): rate-limit drop logs to prevent memory spikes#2721
Merged
Conversation
Signed-off-by: Aryan Bakliwal <[email protected]>
e558993 to
3ebd119
Compare
achrefbensaad
approved these changes
Jun 30, 2026
Aryan-sharma11
approved these changes
Jun 30, 2026
12 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose of PR?:
During high-event loads (e.g., thousands of events per second) where connected clients cannot consume the stream fast enough, the Feeder's internal client broadcast channels fill up. The previous implementation executed
KubeArmor/KubeArmor/feeder/feeder.go
Line 926 in 27ded4a
for every single dropped event.
Spamming the standard output logger thousands of times per second resulted in the KubeArmor's memory usage spike exponentially.
This PR adds a counter to track dropped logs, printing a single warning for every 10,000 dropped logs to prevent memory spikes.
Fixes #
Does this PR introduce a breaking change?
No
If the changes in this PR are manually verified, list down the scenarios covered:

Additional information for reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
Checklist:
<type>(<scope>): <subject>