Frequently asked questions

This section contains frequently asked questions about Auditbeat. Also check out the Auditbeat discussion forum.

Because of the way file monitoring is implemented on macOS, you may see a warning similar to the following:

eventreader_fsnotify.go:42: WARN [audit.file] Failed to watch /usr/bin: too many
open files (check the max number of open files allowed with 'ulimit -a')

To resolve this issue, run Auditbeat with the ulimit set to a larger value, for example:

sudo sh -c 'ulimit -n 8192 && ./Auditbeat -e

Or:

sudo su
ulimit -n 8192
./auditbeat -e

If you need to limit bandwidth usage, we recommend that you configure the network stack on your OS to perform bandwidth throttling.

For example, the following Linux commands cap the connection between Auditbeat and Logstash by setting a limit of 50 kbps on TCP connections over port 5044:

tc qdisc add dev $DEV root handle 1: htb
tc class add dev $DEV parent 1:1 classid 1:10 htb rate 50kbps ceil 50kbps
tc filter add dev $DEV parent 1:0 prio 1 protocol ip handle 10 fw flowid 1:10
iptables -A OUTPUT -t mangle -p tcp --dport 5044 -j MARK --set-mark 10

Using OS tools to perform bandwidth throttling gives you better control over policies. For example, you can use OS tools to cap bandwidth during the day, but not at night. Or you can leave the bandwidth uncapped, but assign a low priority to the traffic.

You may encounter errors loading the config file on POSIX operating systems if:

See Config File Ownership and Permissions for more about resolving these errors.

Either there is a problem with the structure of your config file, or you have used a path or expression that the YAML parser cannot resolve because the config file contains characters that aren’t properly escaped.

If the YAML file contains paths with spaces or unusual characters, wrap the paths in single quotation marks (see Wrap paths in single quotation marks).

Also see the general advice under YAML tips and gotchas.

You may have configured Logstash or Auditbeat incorrectly. To resolve the issue:

Logstash outputs remove @metadata fields automatically. Therefore, if Logstash instances are chained directly or via some message queue (for example, Redis or Kafka), the @metadata field will not be available in the final Logstash instance.

Beats are lightweight data shippers that you install as agents on your servers to send specific types of operational data to Elasticsearch. Beats have a small footprint and use fewer system resources than Logstash.

Logstash has a larger footprint, but provides a broad array of input, filter, and output plugins for collecting, enriching, and transforming data from a variety of sources.

For more information, see the Logstash Introduction and the Beats Overview.

The host running Logstash might be unreachable or the certificate may not be valid. To resolve your issue:

Here are some common errors and ways to fix them:

This happens because your certificate is only valid for the hostname present in the Subject field.

To resolve this problem, try one of these solutions:

This is not a SSL problem. It’s a networking problem. Make sure the two hosts can communicate.

This is not a SSL problem. Make sure that Logstash is running and that there is no firewall blocking the traffic.

A firewall is refusing the connection. Check if a firewall is blocking the traffic on the client, the network, or the destination host.

If you are running multiple Beat instances on the same host, make sure they each have a distinct path.data value.