Administrator Guide
- Documentation for Papertrail
Collect Logs
Collect Logs: Apps & Services
Collect Logs: Hosting Services
Collect Logs: Integrations
- Fluentd
- Librato
- Amazon CloudWatch
- StatHat
- Amazon SNS
- HostedGraphite
- Datadog
- Zapier
- VictorOps
- New Relic traces
- Slack
- Campfire
- PagerDuty
- New Relic Insights
- Pushover
- AppOptics
- Geckoboard
- OpsGenie
- Honeybadger
Manage Logs
Send Logs for Analytics
SolarWinds Users & Orgs
Support and Security
- Security and Compliance
- Support Policy
What's New
- Papertrail Release Notes

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:

Docker syslog driver (--log-driver=syslog; 1.7+ only)
Mounted log volume (-v)

Logspout

To start a logspout container, run:

$ docker run --restart=always -d \
    -v=/var/run/docker.sock:/var/run/docker.sock gliderlabs/logspout  \
    syslog+tls://logsN.papertrailapp.com:XXXXX

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.

Customizing logspout’s messages

The Docker logs that logspout route to Papertrail can be further customized using logspout’s environment variables. One example is setting the source system name to be used in the log messages, as by default logspout uses the container ID for that field.

To start a logspout container that will forward logs with the Docker host's system name as the source system name:

$ docker run --restart=always -d \
    -v=/var/run/docker.sock:/var/run/docker.sock  \
    -e SYSLOG_HOSTNAME=`hostname -s` gliderlabs/logspout \
    syslog+tls://logsN.papertrailapp.com:XXXXX

Alternatively, the Docker container name can be used as the source system name by replacing the value of the SYSLOG_HOSTNAME key as "{{.ContainerName}}".

Other fields of the logs routed via logspout can be also modified such as its Tag, Timestamp, Data, etc.. The syslog format to be used can be set as well, by default it follows the RFC5424 standard. All of this are further describe in the logspout documentation.

Example: logspout with Docker Swarm

This example invocation 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://logsN.papertrailapp.com:XXXXX

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.

Alternatives

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
    image-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://logsN.papertrailapp.com:XXXXX
    image-name

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

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:

To ensure that a container is never affected by log delivery issues, use UDP instead of TCP. UDP does not guarantee delivery, but will also never block the container from running.
To use TCP but reduce the likelihood of log delivery issues affecting the container, use the host-local syslog or a local container, and forward the logs to Papertrail from there.

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.

If using multiple attributes in the tag, use a separator such as / or - rather than a space, as shown in the examples. Alternatively, to override both the hostname and tag, separate attributes with a space (default format or --log-opt syslog-format=rfc3164 only).

Docker Compose

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

logging:
  driver: syslog
  options:
    syslog-address: "udp://logsN.papertrailapp.com:XXXXX"
    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.

Dedicated log collector containers

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.

The scripts are not supported under any SolarWinds support program or service. The scripts are provided AS IS without warranty of any kind. SolarWinds further disclaims all warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The risk arising out of the use or performance of the scripts and documentation stays with you. In no event shall SolarWinds or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the scripts or documentation.