IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

› › ›

Journald input

edit

Journald input

edit

This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.

journald is a system service that collects and stores logging data. The journald input reads this log data and the metadata associated with it.

The simplest configuration example is one that reads all logs from the default journal.

filebeat.inputs:
- type: journald
  id: everything

You may wish to have separate inputs for each service. You can use include_matches to specify filtering expressions. A good way to list the journald fields that are available for filtering messages is to run journalctl -o json to output logs and metadata as JSON. This example collects logs from the vault.service systemd unit.

filebeat.inputs:
- type: journald
  id: service-vault
  include_matches.match:
    - _SYSTEMD_UNIT=vault.service

This example collects kernel logs where the message begins with iptables. Note that include_matches is more efficient than Beat processors because that are applied before the data is passed to the Filebeat so prefer them where possible.

filebeat.inputs:
- type: journald
  id: iptables
  include_matches.match:
    - _TRANSPORT=kernel
  processors:
    - drop_event:
        when.not.regexp.message: '^iptables'

Each example adds the id for the input to ensure the cursor is persisted to the registry with a unique ID. The ID should be unique among journald inputs. If you don’t specify and id then one is created for you by hashing the configuration. So when you modify the config this will result in a new ID and a fresh cursor.

Configuration options

edit

The journald input supports the following configuration options plus the Common options described later.

`id`

edit

An optional unique identifier for the input. By providing a unique id you can operate multiple inputs on the same journal. This allows each input’s cursor to be persisted independently in the registry file.

filebeat.inputs:
- type: journald
  id: consul.service
  include_matches:
    - _SYSTEMD_UNIT=consul.service

- type: journald
  id: vault.service
  include_matches:
    - _SYSTEMD_UNIT=vault.service

`paths`

edit

A list of paths that will be crawled and fetched. Each path can be a directory path (to collect events from all journals in a directory), or a file path. If you specify a directory, Filebeat merges all journals under the directory into a single journal and reads them.

If no paths are specified, Filebeat reads from the default journal.

`backoff`

edit

The number of seconds to wait before trying to read again from journals. The default is 1s.

`max_backoff`

edit

The maximum number of seconds to wait before attempting to read again from journals. The default is 60s.

`seek`

edit

The position to start reading the journal from. Valid settings are:

head: Starts reading at the beginning of the journal. After a restart, Filebeat resends all log messages in the journal.
tail: Starts reading at the end of the journal. This means that no events will be sent until a new message is written.
cursor: On first read, starts reading at the beginning of the journal. After a reload or restart, continues reading at the last known position.
since: Use the since option to determine where to start reading from.

If you have old log files and want to skip lines, start Filebeat with seek: tail specified. Then stop Filebeat, set seek: cursor, and restart Filebeat.

`cursor_seek_fallback`

edit

The position to start reading the journal from if no cursor information is available. Valid options are head, tail and since.

`since`

edit

A time offset from the current time to start reading from. To use since, either the seek option must be set to since, or the seek mode must be set to cursor and the cursor_seek_fallback set to since.

This example demonstrates how to resume from the persisted cursor when it exists, or otherwise begin reading logs from the last 24 hours.

seek: cursor
cursor_seek_fallback: since
since: -24h

`units`

edit

Iterate only the entries of the units specified in this option. The iterated entries include messages from the units, messages about the units by authorized daemons and coredumps. However, it does not match systemd user units.

`syslog_identifiers`

edit

Read only the entries with the selected syslog identifiers.

`transports`

edit

Collect the messages using the specified transports. Example: syslog.

Valid transports:

audit: messages from the kernel audit subsystem
driver: internally generated messages
syslog: messages received via the local syslog socket with the syslog protocol
journal: messages received via the native journal protocol
stdout: messages from a service’s standard output or error output
kernel: messages from the kernel

`include_matches`

edit

A collection of filter expressions used to match fields. The format of the expression is field=value. Filebeat fetches all events that exactly match the expressions. Pattern matching is not supported.

If you configured a filter expression, only entries with this field set will be iterated by the journald reader of Filebeat. If the filter expressions apply to different fields, only entries with all fields set will be iterated. If they apply to the same fields, only entries where the field takes one of the specified values will be iterated.

match: List of filter expressions to match fields. or: The filter expressions listed under or are connected with a disjunction (or). and: The filter expressions listed under and are connected with a conjunction (and).

Please note that these expressions are limited. You can build complex filtering, but full logical expressions are not supported.

The following include matches configuration reads all systemd syslog entries:

include_matches.and:
- match:
  - "journald.process.name=systemd"
  - "systemd.transport=syslog"

To reference fields, use one of the following:

The field name used by the systemd journal. For example, CONTAINER_TAG=redis.
The translated field name used by Filebeat. For example, container.image.tag=redis. Filebeat does not translate all fields from the journal. For custom fields, use the name specified in the systemd journal.

Translated field names

edit

You can use the following translated names in filter expressions to reference journald fields:

Journald field name	Translated name
`COREDUMP_UNIT`	`journald.coredump.unit`
`COREDUMP_USER_UNIT`	`journald.coredump.user_unit`
`OBJECT_AUDIT_LOGINUID`	`journald.object.audit.login_uid`
`OBJECT_AUDIT_SESSION`	`journald.object.audit.session`
`OBJECT_CMDLINE`	`journald.object.cmd`
`OBJECT_COMM`	`journald.object.name`
`OBJECT_EXE`	`journald.object.executable`
`OBJECT_GID`	`journald.object.gid`
`OBJECT_PID`	`journald.object.pid`
`OBJECT_SYSTEMD_OWNER_UID`	`journald.object.systemd.owner_uid`
`OBJECT_SYSTEMD_SESSION`	`journald.object.systemd.session`
`OBJECT_SYSTEMD_UNIT`	`journald.object.systemd.unit`
`OBJECT_SYSTEMD_USER_UNIT`	`journald.object.systemd.user_unit`
`OBJECT_UID`	`journald.object.uid`
`_AUDIT_LOGINUID`	`process.audit.login_uid`
`_AUDIT_SESSION`	`process.audit.session`
`_BOOT_ID`	`host.boot_id`
`_CAP_EFFECTIVE`	`process.capabilites`
`_CMDLINE`	`process.cmd`
`_CODE_FILE`	`journald.code.file`
`_CODE_FUNC`	`journald.code.func`
`_CODE_LINE`	`journald.code.line`
`_COMM`	`process.name`
`_EXE`	`process.executable`
`_GID`	`process.uid`
`_HOSTNAME`	`host.name`
`_KERNEL_DEVICE`	`journald.kernel.device`
`_KERNEL_SUBSYSTEM`	`journald.kernel.subsystem`
`_MACHINE_ID`	`host.id`
`_MESSAGE`	`message`
`_PID`	`process.pid`
`_PRIORITY`	`syslog.priority`
`_SYSLOG_FACILITY`	`syslog.facility`
`_SYSLOG_IDENTIFIER`	`syslog.identifier`
`_SYSLOG_PID`	`syslog.pid`
`_SYSTEMD_CGROUP`	`systemd.cgroup`
`_SYSTEMD_INVOCATION_ID`	`systemd.invocation_id`
`_SYSTEMD_OWNER_UID`	`systemd.owner_uid`
`_SYSTEMD_SESSION`	`systemd.session`
`_SYSTEMD_SLICE`	`systemd.slice`
`_SYSTEMD_UNIT`	`systemd.unit`
`_SYSTEMD_USER_SLICE`	`systemd.user_slice`
`_SYSTEMD_USER_UNIT`	`systemd.user_unit`
`_TRANSPORT`	`systemd.transport`
`_UDEV_DEVLINK`	`journald.kernel.device_symlinks`
`_UDEV_DEVNODE`	`journald.kernel.device_node_path`
`_UDEV_SYSNAME`	`journald.kernel.device_name`
`_UID`	`process.uid`

The following translated fields for Docker are also available:

`CONTAINER_ID`	`container.id_truncated`
`CONTAINER_ID_FULL`	`container.id`
`CONTAINER_NAME`	`container.name`
`CONTAINER_PARTIAL_MESSAGE`	`container.partial`
`CONTAINER_TAG`	`container.image.tag`

Common options

edit

The following configuration options are supported by all inputs.

`enabled`

edit

Use the enabled option to enable and disable inputs. By default, enabled is set to true.

`tags`

edit

A list of tags that Filebeat includes in the tags field of each published event. Tags make it easy to select specific events in Kibana or apply conditional filtering in Logstash. These tags will be appended to the list of tags specified in the general configuration.

Example:

filebeat.inputs:
- type: journald
  . . .
  tags: ["json"]

`fields`

edit

Optional fields that you can specify to add additional information to the output. For example, you might add fields that you can use for filtering log data. 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. If a duplicate field is declared in the general configuration, then its value will be overwritten by the value declared here.

filebeat.inputs:
- type: journald
  . . .
  fields:
    app_id: query_engine_12

`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 added by Filebeat, then the custom fields overwrite the other fields.

`processors`

edit

A list of processors to apply to the input data.

See Processors for information about specifying processors in your config.

`pipeline`

edit

The ingest pipeline ID to set for the events generated by this input.

The pipeline ID can also be configured in the Elasticsearch output, but this option usually results in simpler configuration files. If the pipeline is configured both in the input and output, the option from the input is used.

`keep_null`

edit

If this option is set to true, fields with null values will be published in the output document. By default, keep_null is set to false.

`index`

edit

If present, this formatted string overrides the index for events from this input (for elasticsearch outputs), or sets the raw_index field of the event’s metadata (for other outputs). This string can only refer to the agent name and version and the event timestamp; for access to dynamic fields, use output.elasticsearch.index or a processor.

Example value: "%{[agent.name]}-myindex-%{+yyyy.MM.dd}" might expand to "filebeat-myindex-2019.11.01".

`publisher_pipeline.disable_host`

edit

By default, all events contain host.name. This option can be set to true to disable the addition of this field to all events. The default value is false.

« HTTP JSON input Kafka input »