基于将日志视为事件流的原则，我们正在考虑从使用文件转移到标准输出。虽然我们知道了这种方法的一些好处，但这也意味着我们将获得合并后的格式不同的日志流，在将它们发送到中央系统之前，我们需要再次拆分（Kibana / Splunk /等），或者在里面。
我们想知道是否有任何工具或建议来解决这种情况。
#1 楼
我仍在寻找一种合并/拆分方法，但是与此同时，Kubernetes文档推荐的这种方法似乎是一个不错的解决方案：对每个单独的日志使用sidecar容器。“ sidecar”是您与另一个Docker容器一起使用以某种方式使用的任何Docker容器。在这种情况下，对于您的三个日志中的每个日志，您将有一个单独的容器来扫描或跟踪日志并输出到stdout。
这样，您的每个log-sidecar-containers都有来自其自己的stdout的自己的docker-log。像这样分开，您可以使用标准的docker（和kubernetes等）实践来分离或聚合。 Kubernetes页面必须这样说：
这种方法使您可以将多个日志流与应用程序的不同部分分开，其中一些可能不支持对stdout或stderr的写入。重定向日志的逻辑很小，因此几乎没有很大的开销。此外，由于stdout和stderr由kubelet处理，因此您可以使用诸如kubectl日志之类的内置工具。
“单独的日志流”源于docker的内置标记适用于来自不同容器的日志，如docker文档中所述：
tag log选项指定如何格式化标识
容器日志消息的标签。默认情况下，系统使用容器ID的前12个
字符。要覆盖此行为，请指定一个
标签选项
评论
值得一提的是这种log-sidecar-containers方法的缺点，引用：“请注意，尽管CPU和内存使用率较低，但将日志写入文件然后将其流式传输到stdout可能会使磁盘使用率翻倍”。我想知道是否有人在实践中尝试这种方法。
– yusong
19-10-22在17:16
#2 楼
将它们合并为一个流以便稍后进行拆分的想法听起来很痛苦。我没有理由自己做，但是这是我要开始的地方：运行docker容器时，请创建一个易于查看的卷/ host上的/ ship日志。
使用remote_syslog2之类的东西将日志发送到日志收集器中
在主机上进行一些设置有点不那么优雅很好，但是如果您使用ansible之类的东西可以在其中运行剧本并在部署到盒子的过程中进行设置，那应该还不错。
评论
该解决方案可以与命名管道结合使用，命名管道的唯一问题是它们现在不能在所有系统上正常工作。它们在Mac上不起作用
–詹斯
19年5月27日在2:23
评论
我认为这不值得。为什么仅出于某些“原则”而努力工作以合并然后拆分日志流？文件很好。文件工作。听起来工程过度。我会说也许将所有日志（带有不同标签等）通过管道传输到syslog中，但是我必须说，如果我的团队中有人建议这样做。..我会感到失望。因为使用文件还有其他一些管理方面的噩梦，特别是如果它们是从docker容器内部生成的。目前看来，从切换到标准输出的弊端超过了用例的好处，但是基于文件的方法已经遇到了麻烦
我不知道“噩梦”。我知道这是他们已经完成一段时间的方式，并且有很多软件可以帮助您完成此任务。日志文件被轮换，并带有检查点读取-文件是一个很好的抽象。由于害怕旧的，熟悉的模式，我不会接受给我带来新噩梦的原则。您的日志记录将被写入文件或在内存中处理（至少要在容器中移动它们）。祝您好运，通过内存中的流分割器和合并实现日志文件的可靠性。
@AssafLavie您应该在一个可能被投票的答案中写它。恕我直言，这是一个完全正确的观点。
我来到这里是同样的问题。一个简单的事实是，Docker的内置日志记录功能取决于将要输出到stdout / stderr的所有内容，因此日志记录驱动程序和围绕它构建的第三方工具生态系统也是如此。我也很想将所有日志都转储到主机卷中，但是我知道当我的容器移动到k8s或openshift或gke或其他东西时，我将不得不继续前进并进行管理，而如果我遵循docker stdout方法将更加平滑。同时，我将继续寻找这个合法问题的答案