-
Notifications
You must be signed in to change notification settings - Fork 912
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
Unexpected drop_pct value #2111
Comments
Thanks for looking into this with me @Andreagit97 and @jasondellaluce. Some of the surprising stats being reported in 0.31.1 included drop_pct > 200, so it couldn't have just been caused by individual events being counted as drops twice:
I have now upgraded 20,000+ Falco instances to 0.32.1 so we should get some good data on the impact of previous changes. I also look forward to testing the impact of #2128. |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via /~https://github.com/falcosecurity/community. /lifecycle stale |
I think Falco 0.33.0 (released in few days) should have this solved! Looking forward to hear more once the release is available! |
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via /~https://github.com/falcosecurity/community. /lifecycle rotten |
Yeah, I think we could let poiana close it if we have no more feedback :) |
Resolved by #2128. |
Describe the bug
The expected value for drop_pct is the percentage of total events that were dropped, but that doesn't appear to be the value reported. While troubleshooting high numbers of dropped events on some systems, I found that the drop_pct sometimes exceeded 100%. It looks like Falco is not including the dropped events in the total when calculating drop_pct.
How to reproduce it
Note: this will reproduce the problem as long as it drops at least one event in one minute.
Expected behaviour
I expect the drop_pct to show dropped events as a percent of total events (e.g. if 1000 events are processed and 10 are dropped then drop_pct should be 1).
Screenshots
Environment
Additional context
The text was updated successfully, but these errors were encountered: