Heroku在其十二要素应用清单中将日志描述为简单的事件流：
日志是从所有正在运行的进程和支持服务的输出流中收集的按时间排序的聚合事件流。原始格式的日志通常是一种文本格式，每行一个事件（尽管来自异常的回溯可能跨越多行）。日志没有固定的开头或结尾，但是只要应用程序正在运行，日志就会连续不断地流动。
此外，应用程序应只将日志写入stdout，而将任务留在“环境”中。
stdout
十二要素应用程序永远不会将自己的输出流路由或存储。它不应尝试写入或管理日志文件。而是，每个正在运行的进程将其未缓冲的事件流写入stdout。在本地开发期间，开发人员将在其终端的前台查看此流，以观察应用程序的行为。 在登台或生产部署中，每个流程的流都将由执行环境捕获，并与应用程序中的所有其他流一起整理，并路由到一个或多个最终目标以进行查看和长期存档。这些存档目标对应用程序不可见或不可配置，而是由执行环境完全管理。开源日志路由器（例如Logplex和Fluent）可用于此目的。
十二要素应用程序永远不会将自己的输出流路由或存储。它不应尝试写入或管理日志文件。而是，每个正在运行的进程将其未缓冲的事件流写入stdout。在本地开发期间，开发人员将在其终端的前台查看此流，以观察应用程序的行为。
在登台或生产部署中，每个流程的流都将由执行环境捕获，并与应用程序中的所有其他流一起整理，并路由到一个或多个最终目标以进行查看和长期存档。这些存档目标对应用程序不可见或不可配置，而是由执行环境完全管理。开源日志路由器（例如Logplex和Fluent）可用于此目的。
那么，就可靠性，效率和易用性而言，在docker环境中实现此目标的最佳方法是什么？我认为以下问题浮现在脑海：
docker logs
docker run --volume=[]
Docker 1.6 引入了日志驱动程序的概念，以提供对日志输出的更多控制。的--log- driver标志提供配置，其中stdout与stderr从在容器中运行的进程应被定向。另请参阅配置日志记录驱动程序。
--log- driver
stderr
有几个驱动程序可用。请注意，除了json-file禁用以外，所有这些都禁止使用docker logs收集容器日志。
json-file
/var/lib/docker/containers/<containerid>/<containerid>-json.log
--log-opt
** awslogs-将日志消息写入AWS CloudWatch Logs
Docker 1.8的新功能
** Docker 1.9的新功能
例如：
docker run --log-driver=syslog --log-opt syslog-address=tcp://10.0.0.10:1514 ...
这是Docker推荐的软件解决方案，可将其日志消息写入stdout＆stderr。但是，某些软件不会将日志消息写入stdout/stderr。例如，它们改为写入日志文件或syslog。在这种情况下，下面原始答案中的某些细节仍然适用。回顾一下：
stdout/stderr
如果应用程序写入本地日志文件，请从主机挂载卷（或使用仅数据容器到该容器，然后将日志消息写入该位置。
如果应用程序写入syslog，则有以下几种选择：
/dev/log
-v /dev/log:/dev/log
不要忘记，容器中的所有日志都应该像在主机OS上一样进行轮换。
依靠Docker自己的日志工具（docker日志）是否安全？
docker logs每次都打印整个流，而不仅仅是新的日志，因此不合适。docker logs --follow将提供tail -f类似的功能，但随后您将始终运行一个Docker CLI命令。因此，尽管可以 安全 运行docker logs，但不是最佳选择。
docker logs --follow
tail -f
在不分离的情况下运行docker并将其输出视为日志流是否安全？
您可以使用systemd而不是守护进程来启动容器，从而将所有stdout捕获到systemd日志中，然后可由主机根据需要进行管理。
可以将stdout直接重定向到文件（磁盘空间）吗？
您docker run ... > logfile当然可以做到这一点，但是自动化和管理起来感觉很脆弱并且更加困难。
docker run ... > logfile
如果使用文件，它应该在docker映像内还是绑定的卷内（docker run –volume = []）？
如果您在容器中写入内容，则需要运行logrotate或容器中的某些内容来管理日志文件。最好从主机挂载卷并使用主机的日志轮换守护程序对其进行控制。
是否需要对数旋转？
当然，如果该应用编写日志，则需要像在本机OS环境中一样旋转日志。但是，如果您在容器内部进行写操作会比较困难，因为日志文件的位置不太可预测。如果在主机上旋转，则日志文件将位于以下位置，例如，以devicemapper作为存储驱动程序/var/lib/docker/devicemapper/mnt/<containerid>/rootfs/...。要使logrotate在该路径下查找日志，将需要一些难看的包装器。
/var/lib/docker/devicemapper/mnt/<containerid>/rootfs/...
将stdout直接重定向到logshipper（和哪个logshipper）是否安全？
最好使用syslog，并让日志收集器处理syslog。
是否可以选择命名管道（又名FIFO）？
命名管道不是理想的，因为如果管道的读取端死了，则编写器（容器）将遇到断线的情况。即使该事件由应用处理，也将被阻止，直到再次有读者为止。加上它规避docker logs。
另请参阅流利使用docker的这篇文章。
请参阅Jeff Lindsay的工具logspout，该工具从正在运行的容器中收集日志并根据需要路由它们。
最后，请注意，容器中的stdout将记录到主机中的文件中/var/lib/docker/containers/<containerid>/<containerid>-json.log。
