A container can keep running after you close your terminal, but you still need to see what its application is doing. Docker collects the foreground process’s standard output (stdout) and standard error (stderr) as container logs. An application that writes to those streams makes its messages available without a terminal session. section 19.1
# run a detached container:
docker run -d --name timecheck diamol/ch19-timecheck:2e
# check the most recent log entry:
docker logs --tail 1 timecheck
# stop the container and check the logs again:
docker stop timecheck
docker logs --tail 1 timecheck
# check where Docker stores the container log file:
docker container inspect --format='{{.LogPath}}' timecheck
Run the time-check application detached, read its latest log entry, then stop it and read the entry again. The final command shows where Docker stores that container’s log file. section 19.1
Docker stores collected entries in managed JSON files, so logs remain readable after a container stops. Each raw entry records the message, its output stream, and a time. Logging options such as max-size and max-file let you bound the disk space used by rolling log files. section 19.1
No output from docker container logs does not necessarily mean the application is silent. A service or daemon may write to a file or another logging sink instead. Docker does not read an arbitrary sink inside the container. If changing the application is impractical, package a utility that reads its log file and relays entries to stdout. Check both the original file and docker container logs to verify the relay. section 19.2
A relay has costs: the foreground relay must keep running, and retaining both the original file and Docker’s copy uses more disk space. Writing application logs directly to stdout avoids that duplication when the application supports it. section 19.2
For centralized searches, Fluentd can collect container logs, filter them by tag, add fields, and send selected records to Elasticsearch for viewing in Kibana. For example, access-log records can go to Fluentd’s stdout while other application records go to Elasticsearch. Changing the Fluentd configuration can restore those records to Elasticsearch without changing application images. section 19.4 section 19.5
Production takeaway: make every application component’s logs visible as container logs, then let the platform collect and route them. Sending logs directly from each application to a final store may remove a processing layer, but it ties the applications to that destination. section 19.5
