A process can write messages to standard output, or stdout. In a terminal, you see those messages in the window. In a container, Docker watches stdout and standard error (stderr) and collects what the foreground process writes as container logs. For Docker to collect application logs, the application must write them to these streams. section 19.1 section 19.0
Try a container that prints the time every few seconds: `docker run -it diamol/ch19-timecheck:2e`. Each new timestamp appears in your terminal. The foreground process holds that terminal until you stop it with Ctrl-C or Cmd-C. 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 same application detached, then use `docker logs` to read its output. Stopping the container does not immediately remove those logs; the commands also show how to inspect the log-file path Docker manages. section 19.1
A common snag is an application that writes to a file instead. Its log entries exist inside the container, but `docker logs` shows none of them: Docker does not read that application log file as a container log. One workaround is to start a utility alongside the application that reads the file and relays each entry to stdout. Check the trade-off before using it: the relay must keep running, and retaining both the application file and Docker's collected logs uses extra disk space. section 19.2
Writing logs to stdout also keeps the application separate from its final log store. Once Docker can collect the logs, a logging pipeline can send them to a central store; the application need not write directly to Elasticsearch or another destination. section 19.5
