You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to track to track these metrics over time.
Doing so allows us to tune our auditd / auditbeat configuration properly for the observed systems.
An untuned auditd / auditbeat deployment can lead to performance and latency problems. Tracking audit subsystem metrics would be helpful in determining when problems (i.e. lost audit events, latency increases due to consequent backpressure) occur.
It seems that this information is not simply available from file(s) in the /proc directory.
The lost metric is now collected by Auditbeat and reported through the Beats internal metric subsystem. The value is reported as auditd.kernel_lost. See #7179.
So it will show up in logs, be reported in the monitoring data that goes to ES, and be available over HTTP if http.host is configured.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
The kernel audit subsystem metrics are available using the following command,
It would be great to track to track these metrics over time.
Doing so allows us to tune our auditd / auditbeat configuration properly for the observed systems.
An untuned auditd / auditbeat deployment can lead to performance and latency problems. Tracking audit subsystem metrics would be helpful in determining when problems (i.e. lost audit events, latency increases due to consequent backpressure) occur.
It seems that this information is not simply available from file(s) in the /proc directory.
See #7157 ([Auditbeat] Avoid having Linux wait on clearing a backlog) for the motivation behind this feature request.
Thanks!
The text was updated successfully, but these errors were encountered: