Configure 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_fileedit

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"]

nameedit

The name of the Beat. If this option is empty, the hostname of the server is used. The name is included as the agent.name field in each published transaction. You can use the name to group all transactions sent by a single Beat.

Example:

name: "my-shipper"

tagsedit

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"]

fieldsedit

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_rootedit

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

processorsedit

A list of processors to apply to the data generated by the beat.

See Processors for information about specifying processors in your config.

max_procsedit

Sets the maximum number of CPUs that can be executing simultaneously. The default is the number of logical CPUs available in the system.