:type: journald

[id="{beatname_lc}-input-{type}"]
=== Journald input

++++
<titleabbrev>journald</titleabbrev>
++++

experimental[]

https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html[`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.

["source","yaml",subs="attributes"]
----
{beatname_lc}.inputs:
- type: journald
  id: everything
----

You may wish to have separate inputs for each service. You can use
`include_matches` to specify a list of filter expressions that are applied as a
logical OR.  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.

["source","yaml",subs="attributes"]
----
{beatname_lc}.inputs:
- type: journald
  id: service-vault
  include_matches:
    - _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 {beatname_uc} so prefer them where
possible.

["source","yaml",subs="attributes"]
----
{beatname_lc}.inputs:
- type: journald
  id: iptables
  include_matches:
    - _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.

[id="{beatname_lc}-input-{type}-options"]
==== Configuration options

The `journald` input supports the following configuration options plus the
<<{beatname_lc}-input-{type}-common-options>> described later.

[float]
[id="{beatname_lc}-input-{type}-id"]
==== `id`

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.

["source","yaml",subs="attributes"]
----
{beatname_lc}.inputs:
- type: journald
  id: consul.service
  include_matches:
    - _SYSTEMD_UNIT=consul.service

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

[float]
[id="{beatname_lc}-input-{type}-paths"]
==== `paths`

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, {beatname_uc} merges all journals under the directory
into a single journal and reads them.

If no paths are specified, {beatname_uc} reads from the default journal.

[float]
[id="{beatname_lc}-input-{type}-backoff"]
==== `backoff`

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

[float]
[id="{beatname_lc}-input-{type}-max-backoff"]
==== `max_backoff`

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

[float]
[id="{beatname_lc}-input-{type}-seek"]
==== `seek`

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

* `head`: Starts reading at the beginning of the journal. After a restart,
{beatname_uc} resends all log messages in the journal.
* `tail`: Starts reading at the end of the journal. After a restart,
{beatname_uc} resends the last message, which might result in duplicates. If
multiple log messages are written to a journal while {beatname_uc} is down,
only the last log message is sent on restart.
* `cursor`: On first read, starts reading at the beginning of the journal. After
a reload or restart, continues reading at the last known position.

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

[float]
[id="{beatname_lc}-input-{type}-include-matches"]
==== `include_matches`

A list of filter expressions used to match fields. The format of the expression
is `field=value`. {beatname_uc} fetches all events that exactly match the
expressions. Pattern matching is not supported.

To reference fields, use one of the following:

* The field name used by the systemd journal. For example,
`CONTAINER_TAG=redis`.
* The <<{beatname_lc}-input-{type}-translated-fields,translated field name>>
used by {beatname_uc}. For example, `container.image.tag=redis`. {beatname_uc}
does not translate all fields from the journal. For custom fields, use the name
specified in the systemd journal.

[float]
[id="{beatname_lc}-input-{type}-translated-fields"]
=== Translated field names

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

[horizontal]
*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
https://docs.docker.com/config/containers/logging/journald/[Docker] are also
available:

[horizontal]
`CONTAINER_ID`::              `container.id_truncated`
`CONTAINER_ID_FULL`::         `container.id`
`CONTAINER_NAME`::            `container.name`
`CONTAINER_PARTIAL_MESSAGE`:: `container.partial`
`CONTAINER_TAG`::             `container.image.tag`

[id="{beatname_lc}-input-{type}-common-options"]
include::../inputs/input-common-options.asciidoc[]

:type!:
