Journald input

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

An 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. Each journald input must have an unique ID.

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

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

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.

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

Regardless of the value of seek if Filebeat has a state (cursor) for this input, the seek value is ignored and the current cursor is used. To reset the cursor, just change the id of the input, this will start from a fresh state.

A time offset from the current time to start reading from. To use since, seek option must be 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: since
since: -24h

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.

Read only the entries with the selected syslog identifiers.

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

Valid transports:

Filter entries by facilities, facilities must be specified using their numeric code.

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.

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

The following include matches configuration will ingest entries that contain journald.process.name: systemd and systemd.transport: syslog.

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

The following include matches configuration will ingest entries that contain systemd.transport: systemd or systemd.transport: kernel.

include_matches:
  match:
    - "systemd.transport=kernel"
    - "systemd.transport=syslog"

To reference fields, use one of the following:

This option expects a list of parsers that the entry has to go through.

Available parsers:

In this example, Filebeat is reading multiline messages that consist of 3 lines and are encapsulated in single-line JSON objects. The multiline message is stored under the key msg.

filebeat.inputs:
- type: journald
  ...
  parsers:
    - ndjson:
        target: ""
        message_key: msg
    - multiline:
        type: count
        count_lines: 3

See the available parser settings in detail below.

Options that control how Filebeat deals with log messages that span multiple lines. See Multiline messages for more information about configuring multiline options.

These options make it possible for Filebeat to decode logs structured as JSON messages. Filebeat processes the entry by line, so the JSON decoding only works if there is one JSON object per message.

The decoding happens before line filtering. You can combine JSON decoding with filtering if you set the message_key option. This can be helpful in situations where the application logs are wrapped in JSON objects, like when using Docker.

Example configuration:

- ndjson:
    target: ""
    add_error_key: true
    message_key: log

Use the container parser to extract information from containers log files. It parses lines into common message lines, extracting timestamps too.

The following snippet configures Filebeat to read the stdout stream from all containers under the default Kubernetes logs path:

  parsers:
    - container:
        stream: stdout

The syslog parser parses RFC 3146 and/or RFC 5424 formatted syslog messages.

The supported configuration options are:

Example configuration:

- syslog:
    format: rfc3164
    timezone: America/Chicago
    log_errors: true
    add_error_key: true

Timestamps

The RFC 3164 format accepts the following forms of timestamps:

Note: The local timestamp (for example, Jan 23 14:09:01) that accompanies an RFC 3164 message lacks year and time zone information. The time zone will be enriched using the timezone configuration option, and the year will be enriched using the Filebeat system’s local time (accounting for time zones). Because of this, it is possible for messages to appear in the future. An example of when this might happen is logs generated on December 31 2021 are ingested on January 1 2022. The logs would be enriched with the year 2022 instead of 2021.

The RFC 5424 format accepts the following forms of timestamps:

Formats with an asterisk (*) are a non-standard allowance.

Use the include_message parser to filter messages in the parsers pipeline. Messages that match the provided pattern are passed to the next parser, the others are dropped.

You should use include_message instead of include_lines if you would like to control when the filtering happens. include_lines runs after the parsers, include_message runs in the parsers pipeline.

This example shows you how to include messages that start with the string ERR or WARN:

  parsers:
    - include_message.patterns: ["^ERR", "^WARN"]

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

The following translated fields for Docker are also available:

If CONTAINER_PARTIAL_MESSAGE is present and it is true, then the tag partial_message is added to the final event.

The following configuration options are supported by all inputs.

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

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

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

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.

A list of processors to apply to the input data.

See Processors for information about specifying processors in your config.

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

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.

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

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.