15.1.2.3 Syslog Log Driver

The syslog logging driver sends a container's stdout and stderr output to a syslog daemon, either the local host's own syslog service or a remote syslog server, using the long-established syslog protocol that predates containers entirely, making it a natural fit for organizations that already centralize host-level system logs through syslog infrastructure and want container logs to flow through the same pipeline.

Sending to the local syslog daemon

The simplest configuration sends container log output to the syslog service already running on the host, integrating container logs directly into the same local system log stream as every other host-level service:

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

journalctl -t docker

tail -f /var/log/syslog

On hosts where syslog is itself the primary system logging mechanism, this gives container logs the same visibility and retention as any other system service's logs, without needing a separate container-specific logging pipeline at all.

Sending to a remote syslog server

For centralizing logs across multiple hosts, the driver can be pointed at a remote syslog server instead of (or in addition to) the local daemon:

docker run -d --log-driver=syslog --log-opt syslog-address=udp://logs.example.com:514 my-api

docker run -d --log-driver=syslog --log-opt syslog-address=tcp://logs.example.com:514 my-api

UDP is the traditional syslog transport and is lightweight but does not guarantee delivery, meaning log messages can be silently dropped if the network is congested or the remote server is briefly unavailable; TCP trades some of that lightness for delivery guarantees, at the cost of the connection-oriented overhead and the driver needing to handle reconnection if the TCP connection drops.

TLS-encrypted syslog transport

For sending logs over a network that is not fully trusted, the driver supports a TLS-encrypted transport, protecting log content (which can include sensitive operational detail) from interception in transit:

docker run -d --log-driver=syslog \
  --log-opt syslog-address=tcp+tls://logs.example.com:6514 \
  --log-opt syslog-tls-ca-cert=/certs/ca.pem \
  --log-opt syslog-tls-cert=/certs/client-cert.pem \
  --log-opt syslog-tls-key=/certs/client-key.pem \
  my-api

This is generally the appropriate choice when the syslog server is reached over a network segment shared with other tenants or traffic that should not be able to observe the log content in transit.

Syslog facility and severity mapping

The syslog protocol categorizes messages by facility (a rough classification of the subsystem generating the message) and severity, and the driver maps Docker's own log stream distinction (stdout versus stderr) onto this scheme, which matters for how a syslog server's own filtering and routing rules will treat container log messages:

docker run -d --log-driver=syslog --log-opt syslog-facility=local0 my-api

Setting an explicit facility, rather than relying on the default, allows a syslog server's existing routing rules (which frequently filter or route by facility) to treat container logs distinctly from other categories of system log traffic already flowing through the same syslog infrastructure.

No local read-back support

The syslog driver does not support docker logs against the container, since it forwards output directly to the syslog daemon or remote server without retaining a separately queryable local copy:

docker logs my-api

Error response from daemon: configured logging driver does not support reading

Any "tail recent logs of this container" workflow needs to go through whatever tooling is used to query the syslog destination itself, journalctl, a centralized syslog viewer, or the remote server's own interface, rather than through Docker's own command-line tooling.

Combining syslog with dual logging

For cases where both syslog-based centralization and local docker logs access are wanted, Docker's dual logging capability can retain a local cache of log output in addition to forwarding through syslog, addressing the read-back limitation directly:

{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "udp://logs.example.com:514"
  }
}

This trades some additional local resource usage (memory and disk for the cached copy) for the convenience of still being able to use docker logs directly against a container whose primary logging path is syslog.

Tagging messages for identification

Because syslog aggregates messages from many different sources, including a meaningful tag identifying which container or service produced a given message is important for the destination to remain usable once many containers are all forwarding through the same syslog pipeline:

docker run -d --log-driver=syslog --log-opt tag="{{.Name}}/{{.ID}}" my-api

Without an identifying tag, messages from many different containers arriving at the same syslog destination become difficult to attribute to their source, undermining much of the value of having centralized them in the first place.

When syslog is the right choice

The syslog driver makes the most sense for organizations with existing, mature syslog infrastructure that container logs should integrate into directly, particularly in environments where compliance or operational tooling already depends on syslog as the canonical log transport. For greenfield containerized deployments with no existing syslog dependency, a driver designed more specifically around container and cloud-native log volumes and formats, such as a remote-native driver paired with a modern aggregation backend, is generally a better fit.

Common mistakes

• Choosing UDP transport for an environment where guaranteed log delivery matters, without accounting for UDP's potential for silent message loss under network congestion.
• Forgetting that the syslog driver disables docker logs, and not enabling dual logging when local read access is still needed alongside syslog forwarding.
• Sending log content over an unencrypted network connection to a remote syslog server when the network path is not fully trusted.
• Omitting a meaningful tag, making container-originated messages difficult to attribute once aggregated alongside many other sources in the same syslog stream.
• Adopting syslog as the container logging driver in an organization with no existing syslog infrastructure, taking on the protocol's legacy constraints without the benefit of integrating with infrastructure that already exists.

The syslog driver is a deliberate choice for integrating container logs into existing, already-trusted syslog infrastructure, and its main trade-offs, no local read-back without dual logging, transport reliability differences between UDP and TCP, and the need for explicit tagging, are worth weighing against a more container-native alternative for any deployment not already committed to syslog as its log transport.