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.
NOTE: This You are looking at documentation for an older release. For the latest information, see the current release documentation.
Specify general settingsedit
You can specify settings in the journalbeat.yml
config file to control the
general behavior of Journalbeat. This includes:
- Global options that control things like publisher behavior and the location of some files.
- General options that are supported by all Elastic Beats.
Global Journalbeat configuration optionsedit
These options are in the journalbeat
namespace.
registry_file
edit
The name of the registry file. If a relative path is used, it is considered relative to the
data path. See the Directory layout section for details. The default is ${path.data}/registry
.
journalbeat.registry_file: registry
backoff
[5.6.1]
Deprecated in 5.6.1. Use the option under paths
instead.
edit
This option is valid as a global setting under the journalbeat
namespace
or under paths
. For a description of this option, see
backoff
.
max_backoff
[5.6.1]
Deprecated in 5.6.1. Use the option under paths
instead.
edit
This option is valid as a global setting under the journalbeat
namespace
or under paths
. For a description of this option, see
max_backoff
.
seek
[5.6.1]
Deprecated in 5.6.1. Use the option under paths
instead.
edit
This option is valid as a global setting under the journalbeat
namespace
or under paths
. For a description of this option, see
seek
.
include_matches
[5.6.1]
Deprecated in 5.6.1. Use the option under paths
instead.
edit
This option is valid as a global setting under the journalbeat
namespace
or under paths
. For a description of this option, see
include_matches
.
General configuration optionsedit
These options are supported by all Elastic Beats. Because they are common options, they are not namespaced.
Here is an example configuration:
name: "my-shipper" tags: ["service-X", "web-tier"]
name
edit
The name of the Beat. If this option is empty, the hostname
of the server is
used. The name is included as the beat.name
field in each published transaction. You can
use the name to group all transactions sent by a single Beat.
Example:
name: "my-shipper"
tags
edit
A list of tags that the Beat includes in the tags
field of each published
transaction. Tags make it easy to group servers by different logical properties.
For example, if you have a cluster of web servers, you can add the "webservers"
tag to the Beat on each server, and then use filters and queries in the Kibana
web interface to get visualisations for the whole group of servers.
Example:
tags: ["my-service", "hardware", "test"]
fields
edit
Optional fields that you can specify to add additional information to the
output. Fields can be scalar values, arrays, dictionaries, or any nested
combination of these. By default, the fields that you specify here will be
grouped under a fields
sub-dictionary in the output document. To store the
custom fields as top-level fields, set the fields_under_root
option to true.
Example:
fields: {project: "myproject", instance-id: "574734885120952459"}
fields_under_root
edit
If this option is set to true, the custom fields are
stored as top-level fields in the output document instead of being grouped under
a fields
sub-dictionary. If the custom field names conflict with other field
names, then the custom fields overwrite the other fields.
Example:
fields_under_root: true fields: instance_id: i-10a64379 region: us-east-1
processors
edit
A list of processors to apply to the data generated by the beat.
See Filter and enhance the exported data for information about specifying processors in your config.
max_procs
edit
Sets the maximum number of CPUs that can be executing simultaneously. The default is the number of logical CPUs available in the system.