This functionality is experimental and may be changed or removed completely in a future release. Elastic will take a best effort approach to fix any issues, but experimental features are not subject to the support SLA of official GA features.

« Debug

› ›

Frequently asked questions

edit

Frequently asked questions

edit

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

Need to limit bandwidth used by Journalbeat?

edit

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 Journalbeat 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.

Error loading config file?

edit

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

an unauthorized user tries to load the config file, or
the config file has the wrong permissions.

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

Found Unexpected or Unknown Characters?

edit

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.

Logstash connection doesn’t work?

edit

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

Make sure that Logstash is running and you can connect to it. First, try to ping the Logstash host to verify that you can reach it from the host running Journalbeat. Then use either nc or telnet to make sure that the port is available. For example:
```
ping <hostname or IP>
telnet <hostname or IP> 5044
```
Verify that the config file for Journalbeat specifies the correct port where Logstash is running.
Make sure that the Elasticsearch output is commented out in the config file and the Logstash output is uncommented.
Confirm that the most recent Beats input plugin for Logstash is installed and configured. Note that Beats will not connect to the Lumberjack input plugin. To learn how to install and update plugins, see Working with plugins.

@metadata is missing in Logstash?

edit

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.

To preserve @metadata fields, use the Logstash mutate filter with the rename setting to rename the fields to non-internal fields.

Difference between Logstash and Beats?

edit

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.

SSL client fails to connect to Logstash?

edit

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

Make sure that Logstash is running and you can connect to it. First, try to ping the Logstash host to verify that you can reach it from the host running Journalbeat. Then use either nc or telnet to make sure that the port is available. For example:
```
ping <hostname or IP>
telnet <hostname or IP> 5044
```
Verify that the certificate is valid and that the hostname and IP match.

For testing purposes only, you can set verification_mode: none to disable hostname checking.
Use OpenSSL to test connectivity to the Logstash server and diagnose problems. See the OpenSSL documentation for more info.
Make sure that you have enabled SSL (set ssl => true) when configuring the Beats input plugin for Logstash.

Common SSL-Related Errors and Resolutions

edit

Here are some common errors and ways to fix them:

x509: cannot validate certificate for <IP address> because it doesn’t contain any IP SANs

edit

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:

Create a DNS entry for the hostname mapping it to the server’s IP.
Create an entry in /etc/hosts for the hostname. Or on Windows add an entry to C:\Windows\System32\drivers\etc\hosts.
Re-create the server certificate and add a SubjectAltName (SAN) for the IP address of the server. This make the server’s certificate valid for both the hostname and the IP address.

getsockopt: no route to host

edit

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

getsockopt: connection refused

edit

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

No connection could be made because the target machine actively refused it

edit

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

Monitoring UI shows fewer Beats than expected

edit

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

« Debug