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

Alternatives

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

Logspout

To start a logspout container, run:

docker run --restart=always -d \
  -v=/var/run/docker.sock:/var/run/docker.sock gliderlabs/logspout  \
  syslog://logs.papertrailapp.com:1111

Replace logs.papertrailapp.com:1111 with 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://logs.papertrailapp.com:1111

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

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

Alternatives

syslog driver: –log-driver=syslog

Docker can log directly to a syslog destination using:

docker run --log-driver=syslog
  --log-opt syslog-address=[tcp|udp]://host:port
  --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://logs.papertrailapp.com:1234

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

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

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.