Enhanced respone to fsnotify queue overflow errors

Hi Auditbeat folks. I'm considering a feature request, or maybe even a PR to enhance Auditbeat's file_integrity behavior on Linux platforms when the "fsnotify queue overflow" message is encountered. See eventreader_fsnotify.go#L165-L170

The current behavior of Auditbeat is to log the message and then carry on as-is. I'd like to propose a non-default configuration option that would cause auditbeat to perform it's "scan-on-start" behavior when this overflow message is encountered. The reason for this is that file changes that were unable to be pushed into the underlying inotify queue will not be noticed by auditbeat until either the file is changed again, or until the auditbeat service is restarted. While the event(s) that didn't make it into the queue initially are well and truly gone, this new behavior would at least capture the fact that some change occurred.

This isn't a critical need, imo, as there are operational workarounds, e.g. detect the problem via log inspection and manually restart the audtibeat service, modify OS settings to increase queue size thereby minimizing the likelihood of the overflow, etc. The point would be to reduce the need for such workarounds in the first place. Also, I have no idea how useful this would be to the broader community. But it would indeed be handy for us.

Does anyone have thoughts/opinions/ideas? I'd love to hear them.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.