Logging Drivers

Drivers and Defaults

Docker captures each container's stdout/stderr through a logging driver. The default is json-file, one JSON file per container under /var/lib/docker/containers/ — convenient for docker logs, but unbounded until you cap it:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "5" }
}

Set daemon-wide defaults in daemon.json and override per container with --log-driver/--log-opt. Rotation options only apply to containers created after the change — existing containers keep their original driver until recreated.

Shipping to a Log Aggregator

For central search, forward at the daemon instead of polling hosts:

docker run --log-driver=fluentd \
  --log-opt fluentd-address=localhost:24224 \
  --log-opt tag="app.{{.ID}}" myapp

The fluentd driver emits records Fluentd can route to Elasticsearch or similar; syslog targets syslog-address=tcp://host:514 (add syslog-tls-cert for encryption), and awslogs/gcplogs ship straight to cloud providers. Application design stays the same: write logs to stdout as plain lines — JSON on stdout works with every driver, so formatting remains the app's job, transport is the daemon's.

Pitfalls and Interview Angles

docker logs coverage. It only works for drivers that retain local copies — json-file, local, and journald. With fluentd or syslog, docker logs errors out; you read from the collector instead.

Disk fill. Default json-file grows forever; a chatty container can fill the root volume and take the whole host down — rotation is not optional in production.

Double shipping. Running both an aggregator sidecar and a driver-level forward duplicates records and cost; pick one path.

Interview: choose a driver for a given constraint (local debug vs centralized search vs cloud), state the rotation settings you would enforce, and explain why a config change does not affect running containers.