What logging drivers does Docker support, and how do they affect log management?

Why the default driver doesn't scale to real production needs

The default json-file driver (see the lifecycle topic) writes each container's logs to a local file on that specific host's disk, with no automatic rotation configured unless you explicitly set --log-opt max-size/max-file. Across a fleet of many hosts running many containers, this creates several problems. Logs are scattered across many machines with no unified way to search across all of them. A host being replaced (common in autoscaled or ephemeral infrastructure) takes its logs with it. Unbounded log growth can genuinely fill a host's disk if rotation isn't explicitly configured.

Setting a logging driver

docker run --log-driver=syslog --log-opt syslog-address=udp://loghost:514 myapp
docker run --log-driver=fluentd --log-opt fluentd-address=localhost:24224 myapp
docker run --log-driver=awslogs --log-opt awslogs-group=myapp --log-opt awslogs-region=us-east-1 myapp

Or, to set a default for the whole Docker daemon (rather than specifying it per-container):

// /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Common production-oriented drivers

• syslog — forwards to a syslog server, a long-established standard for centralized Unix/Linux logging.
• journald — integrates with systemd's journal on hosts using systemd, useful if the rest of the host's own logging already goes through journald.
• fluentd / gelf — forward to Fluentd or a GELF-compatible endpoint (like Graylog). These are common choices for feeding into an Elasticsearch/Loki-based centralized logging stack, the same kind of architecture covered in the Kubernetes stack's logging question. Here, Docker's own driver mechanism feeds the stack directly, rather than a separate log-shipping DaemonSet.
• awslogs — forwards directly to AWS CloudWatch Logs, a natural fit when already running on AWS infrastructure.

The tradeoff: docker logs stops working locally

docker run --log-driver=awslogs myapp
docker logs myapp
# Error response from daemon: configured logging driver does not support reading

Once a non-default driver is configured, docker logs generally can no longer read the container's log output locally at all. Logs are only accessible through whatever external system the chosen driver forwards to. This is an important, sometimes-surprising tradeoff for teams used to reaching for docker logs directly during troubleshooting. The mental model needs to shift to "check the centralized logging system," not "SSH into the host and run docker logs."

Why this matters for anything beyond a single-host deployment

Centralized logging isn't optional once you're running more than a handful of containers across more than one host. Without it, diagnosing an issue that spans multiple services (a request that touches three different containers, possibly on three different hosts) requires manually checking logs on each machine individually. This becomes impractical fast. A centralized logging driver, feeding into a searchable system, is what makes cross-service, cross-host troubleshooting actually tractable at any real scale. It only needs to be configured once at the daemon level, so every container benefits without per-container setup.