应用容器化后，建议日志是落盘后再采集还是直接通过网络发到外部呢？

三种常见日志收集解决方案
1.每个app的镜像中都集成日志收集组件：

        优点：
            部署方便，kubernetes的yaml文件无须特别配置，可以为每个app自定义日志收集配置
        缺点：
            强耦合，不方便应用和日志收集组件升级和维护且会导致镜像过大

2.单独创建一个日志收集组件跟app的容器一起运行在同一个pod中：

        优点：
            低耦合，扩展性强，方便维护和升级
        缺点：
            需要对kubernetes的yaml文件进行单独配置，略显繁琐

3：将所有的Pod的日志都挂载到宿主机上，每台主机上单独起一个日志收集Pod：

        优点：
            完全解耦，性能最高，管理起来最方便
        缺点：
            需要统一日志收集规则，目录和输出方式

建议直接网络发出吧，只是占用网络io，可以配置单独的网卡走日志流量，写入到es或其他日志存储分析工具中进行分析。如果先落盘，最终还是要采集分析的，对于日志生产端，同时占用网络和存储的io。需要注意的是，不管走网络，还是采集落盘在进行分析，都联系与生产读写及网络做分开，特别是高负载的情况。
但是网络发出实现上应该比较复杂，增加节点，而且万一有问题，会出现日志丢失的情况。落盘采集简单可靠，方案成熟，要求不是特别好的话，生产环境落盘采集感觉会好一些。

可以考虑的方面：
1. 性能考量
涉及到读写盘、读写网络接口的性能问题，涉及到大量容器的读写时，IO孰高孰低，是否会因为日志导致整体程序崩溃等。相比而言，本地落盘读写速速度快，但对容器云平台来说，本地落盘容器日志的处理和收集又相对繁琐，如：如何动态搜集日志数据、何时清理本地盘数据？
2. 数据量考量
如果日志量非常大，因为日志导致的带宽增加性价比会更低。

考虑以上两个方面，我们的方案是：日志先本地存储，后再进行转储搜集。

 传统架构

在传统架构下日志是落盘后再采集还是直接通过网络发到外部两种方案在业界均有使用。日志落盘后采集可以基于丰富的开源框架统一进行日志采集，整个日志采集完全与业务解耦，并可以独立管理部署，但是对于IO的要求较高，一般来说业务日志通常会使用此类方式进行日志采集；直接采集日志整体方案更为复杂，一般通过异步进程来处理日志，整体耦合性高，代码侵入性高，但是整个日志处理逻辑可以通过编码处理，并通过内存传输，可以通过编码进行细粒度处理，常用于日志完整性要求高的场景。综上，可以根据日志的类型和完整性要求来选择日志的采集模式。

 云原生架构

在云原生架构下， 直接采集日志基本已经废弃，业界几乎都选择了落盘后再采集日志的方案，整体方案大致分为两类：
1. 以sidecar的模式部署日志采集器，通过共享存储的方案采集业务容器产生的日志
2. 以daemonset的模式部署日志采集器，通过扫描node节点对应pod目录采集日志
两种方式各有优劣

 云原生采集方案对比

|   |daemonset采集 | sidecar采集 |
| ------------ | ------------ | ------------ |
| 采集日志类型 | 标准输出+文件 | 文件 |
| 部署复杂度 | 较高 | 高，需要独立维护sidecar |
| 日志分类存储 | 容器路径标准化映射 | 完全可定制 |
| 性能 | 中等规模 | 无限制 |
| 隔离性 | 较高，逻辑隔离 | 高，物理隔离 |
| 资源占用 | 较高 | 高，与容器规模正相关 |
| 可扩展性 | 低，集群统一配置 | 高 |

可以看到sidecar的模式优于 daemonset，但是整体方案复杂度更高，没有办法统一管理日志采集器，每个应用独立维护sidecar，但是复杂度的问题也有方案可以解决的，通过云原生的mutating-admission-webhook可以在容器部署前注入对应的日志采集sidecar，统一管理sidecar并基于应用分类做到统一管理。在这里推荐一个阿里开源的workload:openKruise,其中sidecarSet可以指定域进行sidecar注入，完成日志采集器的统一管理。

目前我们内部推荐的方案是采用双日志方案，保存两份日志，可进一步保障日志数据安全，方便后续日志分析和故障定位。一方面容器应用的日志可以输入出到标准输出或文件中，输出到标准输出的日志，可通过ELK组合开源工具收集到ElasticSearch 集群 中供后续查询，如果应用无法输出到标准输出，则使用sidecar方式直接发送到 ElasticSearch集群 ，通过另外的日志服务系统提供日志查询服务；另一方面日志文件持久化到共享存储中，支持通过服务器查看。

依我个人观点，日志直接发出去。但这个方案通常会复杂些。要保证日志发送失败不会导致服务异常。就优先级别来说，前提是保障业务运行。日志可以丢，服务不能受影响。

至于选择哪种方式，考虑自身的能力和整体的架构和组件配置。

1. 落盘是简单的方式，通常不会带来额外影响，除非IO有问题
2. 在业务里面直接发送日志到外部，比如通过消息方式，需要和消息服务器建立连接，在服务内需要引入日志消息发送组件（也就是说需要先封装日志发送client组件），连接可能会断开，网络io也可能会是瓶颈，等等，所以整体方案会复杂化
不过这个方案是考虑整体趋势和融合架构的结果，有效率方面的考虑，日志发送通常也要考虑批量处理等
这个方案有个好处是基于实时事件处理的事中处理可以构建起来，所以说是从整体方案来考虑的。
3. 容器可以直接打印日志到标准输出，从标准输出采集然后发送到日志中心，目前我们采用的是这种方案。这种方案也相对简单

不过依然需要注意的问题是，日志信息一定要格式标准化，分级，运行时可调整记录级别。

容器日志收集有三种方案：

第一种，在 Node 上部署 logging agent，将日志文件转发到后端存储里保存起来， 这里的核心就在于 logging agent ，它一般都会以 DaemonSet 的方式运行在节点 上，然后将宿主机上的容器日志目录挂载进去，最后由 logging-agent 把日志转发出去。举个例子，我们可以通过 Fluentd 项目作为宿主机上的 logging-agent，然后把日志转发到远 端的 ElasticSearch 里保存起来供将来进行检索。
在 Node 上部署 logging agent 最大的优点，在于一个节点只需要部署一个 agent，并且不会对应用和 Pod 有任何侵入性。所以，这个方案，在社区里是最常用的一种。 但是也不难看到，这种方案的不足之处就在于，它要求应用输出的日志，都必须是直接输出到容 器的 stdout 和 stderr 里。

所以， Kubernetes 容器日志方案的第二种，就是对这种特殊情况的一个处理，即:当容器的日 志只能输出到某些文件里的时候，我们可以通过一个 sidecar 容器把这些日志文件重新输出到 sidecar 的 stdout 和 stderr 上，这样就能够继续使用第一种方案了。 在这种情况下，你用 kubectl logs 命令是看不到应用的任何日志的。而且最常用的方案一，也是没办法使用的。那么这个时候，我们就可以为这个 Pod 添加两个 sidecar 容器，分别将上述两个日志文件里的内容重新以 stdout 和 stderr 的方式输出出来。 这时候，你就可以通过 kubectl logs 命令查看这两个 sidecar 容器的日志，间接看到应用的日 志内容了。 由于 sidecar 跟主容器之间是共享 Volume 的，所以这里的 sidecar 方案的额外性能损耗并不 高，也就是多占用一点 CPU 和内存罢了。但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件:一份是应用自己写入 的;另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的浪费。所 以说，除非万不得已或者应用容器完全不可能被修改，否则我还是建议你直接使用方案一，或者 直接使用下面的第三种方案。

第三种方案，就是通过一个 sidecar 容器，直接把应用的日志文件发送到远程存储里面去。 也就是相当于把方案一里的 logging agent，放在了应用 Pod 里。 在这种方案里，你的应用还可以直接把日志输出到固定的文件里而不是 stdout，你的 logging- agent 还可以使用 fluentd，后端存储还可以是 ElasticSearch。只不过， fluentd 的输入源， 变成了应用的日志文件。一般来说，我们会把 fluentd 的输入源配置保存在一个 ConfigMap 里。 Fluentd 容器使用的输入源，就是通过引用这个 ConfigMap 来指定的。 需要注意的是，这种方案虽然部署简单，并且对宿主机非常友好，但是这个 sidecar 容器很可能 会消耗较多的资源，甚至拖垮应用容器。并且，由于日志还是没有输出到 stdout 上，所以你通 过 kubectl logs 是看不到任何日志输出的。

综合对比以上三种方案，我比较建议你将应用日志输出到 stdout 和 stderr，然后通过在宿主机上部署 logging-agent 的方式来集中处理日志。这种方案不仅管理简单，kubectl logs 也可以用，而且可靠性高，并且宿主机本身，很可能就 自带了 rsyslogd 等非常成熟的日志收集组件来供你使用。除此之外，还有一种方式就是在编写应用的时候，就直接指定好日志的存储后端，在这种方案下，Kubernetes 就完全不必操心容器日志的收集了，这对于本身已经有完善的日志 处理系统的公司来说，是一个非常好的选择。

最后需要指出的是，无论是哪种方案，你都必须要及时将这些日志文件从宿主机上清理掉，或者给日志目录专门挂载一些容量巨大的远程盘。否则，一旦主磁盘分区被打满，整个系统就可能会陷入奔溃状态，这是非常麻烦的。

我觉得能直接发就直接发，时效性，性能要求都好很多。另外磁盘占用也少很多。
不能发的话就保存再转发吧，

1.对于集群级别的日志采集方案还是选择不落盘采集，避免因为I/O影响性能。
2.应用级别的日志采集，分情况，能标准输出的也不落盘；只能打日志文件的那就先落盘后再sidecar标准输出或者直接转发到后端

先说结论，建议直接容器标准输出送到ES。
1、为什么容器化环境需要统一日志？是因为应用容器化后，容器扩缩容非常方便，应用实例数量有可能很多，在故障排错过程中，相对传统直接登录主机看日志方式，容器化环境错误日志查看更难，所以需要统一日志存储。