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 writes each container's logs to a local file on that host's disk, with no automatic rotation unless you explicitly set --log-opt max-size/max-file. Across a fleet of many hosts running many containers, this causes problems: logs are scattered across machines with no unified way to search them, a host being replaced (common in autoscaled or ephemeral infrastructure) takes its logs with it, and unbounded log growth can genuinely fill a host's disk if rotation isn't 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 set a default for the whole Docker daemon, instead of 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. Common choices for feeding an Elasticsearch/Loki-based centralized logging stack — the same kind of architecture used for centralized logging in Kubernetes, except Docker's own driver feeds the stack directly instead of a separate log-shipping DaemonSet.
• awslogs — forwards directly to AWS CloudWatch Logs, a natural fit when already running on AWS.

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. Logs are only accessible through whatever external system the chosen driver forwards to. This can surprise 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 — means manually checking logs on each machine, which becomes impractical fast. A centralized logging driver feeding into a searchable system is what makes cross-service, cross-host troubleshooting actually tractable at scale, and it only needs configuring once at the daemon level for every container to benefit.