How do you view and manage container logs?

Basic usage

docker logs my-container                # show all accumulated logs
docker logs -f my-container               # follow/stream logs live, as they're written
docker logs --tail 100 my-container         # only the most recent 100 lines
docker logs --since 10m my-container          # only logs from the last 10 minutes
docker logs -t my-container                    # include timestamps for each line

These flags combine freely — docker logs -f --tail 50 --since 5m my-container follows live output, starting from the last 50 lines within the last 5 minutes.

Where these logs actually come from

Docker only captures what a container's main process writes to stdout and stderr. This is exactly why best practice (borrowed from the twelve-factor app methodology, see the production topic) is for containerized applications to log to stdout/stderr rather than writing to internal log files. Only stdout/stderr is automatically captured by Docker's logging mechanism, without any extra configuration.

docker inspect my-container --format='{{.HostConfig.LogConfig.Type}}'
# json-file   (the default logging driver)

By default, Docker uses the json-file logging driver, which writes each log line as a JSON object to a file on the host's disk (typically under /var/lib/docker/containers/<container-id>/) — this is what docker logs actually reads from.

The default's real limitations at scale

docker inspect my-container --format='{{.LogPath}}'

The default json-file driver has no automatic log rotation configured out of the box. A long-running, chatty container can, in principle, fill up the host's disk with an ever-growing log file if this isn't explicitly configured. It's also inherently tied to that one specific host and container. There's no built-in mechanism to search or aggregate logs across many containers or many hosts. This becomes a real operational gap the moment you're running more than a handful of containers.

Configuring log rotation for the default driver

docker run --log-opt max-size=10m --log-opt max-file=3 myapp

This caps each log file at 10MB, keeping at most 3 rotated files — a reasonable minimum safeguard for any container running the default driver in a context where unbounded log growth would actually be a problem.

Alternative logging drivers for production

docker run --log-driver=syslog --log-opt syslog-address=udp://loghost:514 myapp
docker run --log-driver=json-file --log-driver=awslogs --log-opt awslogs-group=myapp myapp

Docker supports several alternative logging drivers (syslog, journald, fluentd, awslogs, gelf, and others) that forward log output directly to an external logging system rather than (or in addition to) writing local JSON files. This is the standard approach for genuine production log management, especially once running many containers across many hosts. Centralized, searchable, durable logging becomes essential rather than optional at that point, mirroring the DaemonSet-based log-shipping pattern covered in the Kubernetes stack.

A key caveat about switching drivers

Once you configure a non-default logging driver (like syslog or awslogs), docker logs generally stops working for that container, since it specifically reads from the local json-file format. Logs are instead only accessible through whatever external system the chosen driver forwards them to. This is an important tradeoff to know before switching drivers in an environment where people are used to reaching for docker logs directly.