Configuring centralized logging from Docker

To send logs from applications running in a Docker container, choose based on your Docker version and deployment preferences.

Here’s a screenshot of Docker logs in Papertrail’s event viewer.

Log aggregation methods

Not sure? Use a logspout container.

I’m… Use.. Notes
a typical Docker user logspout container Most popular
brand new to Docker remote_syslog2 & rsyslog Same as non-Docker setup


If neither of the methods above fit your environment, these are also viable:


To start a logspout container, run:

docker run --restart=always -d \
  -v=/var/run/docker.sock:/var/run/docker.sock gliderlabs/logspout  \

Replace logsN and XXXXX with details from one of your Papertrail log destinations.

The --restart ensures that it will be re-run automatically at host boot. Docker run behavior is sensitive to the ordering of some arguments, so be aware of ordering if altering the suggested command.

Example: logspout with Docker Swarm

Here is an example invocation which starts logspout as part of a Docker Swarm cluster. Docker will start one logspout service per node “global” mode) and expose /var/run/docker.sock from each node:

docker service create --name log \
  --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
  --mode global gliderlabs/logspout syslog+tls://

remote_syslog2 & rsyslog

Keep it simple. Use Papertrail’s non-Docker-specific methods for sending system and app logs. For example, send app log files with remote_syslog2 and system logs with rsyslog. These run in container(s) and host(s).

This is the same method used by any other Linux logging configuration, such as for a physical system or Xen VM.

For app logs, follow the steps on text log files.

For system logs, follow the steps on systemd or standard syslog setup.

This works particularly well when your containers are more like traditional systems, such as when they were migrated directly from dedicated systems.


syslog driver: –log-driver=syslog

Docker can log directly to a syslog destination using:

docker run --log-driver=syslog
  --log-opt syslog-address=[udp|tcp+tls]://host:port
  --log-opt tag=optional-container-name

See –log-driver and syslog options.

The destination can be a syslog daemon running on the host, a syslog daemon running on another container, or Papertrail itself (see Add Systems for host and port). For example:

docker run --log-driver=syslog
  --log-opt syslog-address=udp:// 

replacing logsN and XXXXX with details from the Papertrail log destination (and image-name with the name of the desired image to run).

Note that using an alternative log driver means that docker logs will no longer display logs. To access logs, go to the syslog daemon or Papertrail.

Important: TCP connection failure on startup means container failure

If using TCP/TLS, failure to connect to the syslog endpoint will result in the container not starting. Docker currently prioritizes not losing logs over starting a container without log delivery. See #21966: If a remote TCP syslog server is down, docker does not start. There are two ways to eliminate or mitigate this issue:

Configuring syslog tags

By default, Docker uses the first 12 characters of the container ID to tag log messages. To choose a different tag or include other attributes in the tag, see log tags.

Docker Compose

If using Docker Compose, add something like the following as an entry:

  driver: syslog
    syslog-address: "udp://"
    tag: "{{.Name}}/{{.ID}}"

This also shows an example of a custom tag.

Mounted log volume: docker -v

Have the containers log to files in a directory/volume that’s shared with (mounted from) the host. See Mount a host directory as a data volume and docker -v.

This can be one directory per container or a shared directory for all containers.

Then on the host, use Papertrail’s typical techniques for sending logs from files.

Alternative: If you need to keep the host’s workload to a minimum or simply prefer to completely separate unrelated concerns, use log collector containers to send logs (instead of a daemon on the host). This container image does nothing except watch a log file (exposed as a docker -v mount) and send the contents to Papertrail.