15.1.2.4 Journald Log Driver

The journald logging driver sends a container's stdout and stderr output to systemd's journal, the same logging system that captures output from native systemd-managed services on the host, making it the natural choice for any host that already standardizes on journald for system logging and wants container logs to appear in that same, unified journal rather than in a separate, container-specific store.

Why journald integration matters on systemd hosts

Most modern Linux distributions use systemd and journald as their default system logging mechanism, and a host that already relies on journalctl for every other service benefits from having container logs appear in the same place, searchable with the same tool and subject to the same retention and rotation policy as the rest of the system's logs:

docker run -d --log-driver=journald my-api

journalctl CONTAINER_NAME=my-api

This integration also means container logs inherit journald's own indexing and structured query capabilities directly, without needing a separate container-specific log viewer for basic inspection tasks.

Querying container logs through journalctl

journald attaches several container-specific fields to each log entry, which can be used as filters directly in journalctl queries:

journalctl CONTAINER_ID=3f29a8c1d8e2

journalctl CONTAINER_NAME=my-api --since "10 minutes ago"

journalctl CONTAINER_NAME=my-api -o json | jq .

Requesting JSON output through journalctl -o json provides a structured, machine-parseable representation of each log entry, including journald's own metadata fields alongside the container's actual message content, which is useful for scripting or for feeding journald's output into a separate aggregation pipeline.

docker logs compatibility

Unlike the syslog driver, journald supports docker logs directly, since journald itself supports the structured, indexed querying that the read-back interface depends on:

docker logs my-api
docker logs --since 1h my-api

This dual accessibility, through both docker logs and journalctl directly, is one of journald's practical advantages over several other drivers that sacrifice local read-back entirely in exchange for remote forwarding.

Persistent versus volatile journal storage

journald's own storage configuration determines whether the journal (and therefore the container logs flowing into it) persists across a host reboot or is stored only in memory and lost on restart:

# /etc/systemd/journald.conf
[Journal]
Storage=persistent

systemctl restart systemd-journald

Confirming that the host's journald is configured for persistent storage is worth doing explicitly when relying on the journald driver for container logs, since a volatile journal configuration would mean container log history disappears on every host reboot, which may be a surprising gap if not anticipated.

Retention and size limits

journald's own size and retention limits, configured independently of Docker, apply to container log entries the same way they apply to every other source writing into the journal, which means rotation and disk usage bounds need to be managed at the journald configuration level rather than through Docker's own --log-opt settings:

[Journal]
SystemMaxUse=2G
MaxRetentionSec=30day

Because journald's retention applies across every log source sharing the journal, a host running many verbose containers can cause journald's overall retention window to shrink for every other service's logs as well, simply due to shared storage pressure, which is worth monitoring on hosts running a significant number of containers alongside native services.

Forwarding journal entries onward for centralized aggregation

For multi-host deployments, journald itself supports forwarding to a remote journal server, or a separate collector can read from the local journal and forward entries to a centralized aggregation system:

systemctl enable --now systemd-journal-upload

[Upload]
URL=https://logs.example.com:19532

Alternatively, a collector like Fluent Bit can read directly from the systemd journal as its input source, extracting container log entries (identified by their journald container-specific fields) and forwarding them to whichever aggregation backend the rest of the deployment already uses:

[INPUT]
    Name systemd
    Tag host.*
    Systemd_Filter _SYSTEMD_UNIT=docker.service

Setting journald as a daemon-wide default

For a host fully standardized on systemd and journald, setting it as Docker's default logging driver ensures every container's logs land in the same unified journal without needing per-container configuration:

{
  "log-driver": "journald"
}

systemctl restart docker

Limitations to be aware of

journald's container-specific metadata fields and query capabilities are specific to journald and systemd; this driver is therefore a poor fit for non-systemd hosts, and the structured fields it attaches are not the same as the labels or environment variable attachment options some other drivers, like json-file, support directly. Additionally, because the journal is a shared resource across the entire host, a single noisy container can affect retention for every other log source sharing that same journal storage.

Common mistakes

• Relying on the journald driver on a host where journald's own storage is configured as volatile, losing container log history on every reboot.
• Not accounting for journald's shared retention behavior, where a single verbose container can shrink the effective retention window for every other service's logs on the same host.
• Assuming journald's container metadata fields are portable to other drivers or other log viewing tools, rather than being specific to journald's own query interface.
• Choosing journald on a non-systemd host or container platform where the driver's core integration benefit does not apply at all.
• Forgetting to configure journald's own size limits, relying only on Docker-level options that the journald driver does not actually use for retention control.

The journald driver is the right choice specifically for systemd-managed hosts that want container logs unified with the rest of the system's logging, offering both docker logs and journalctl access, but its retention and storage behavior is governed by journald's own configuration rather than Docker's logging options, and that configuration needs to be managed explicitly to avoid both unexpected log loss and unexpected pressure on shared journal storage.