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

 传统架构

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

 云原生架构

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

 云原生采集方案对比

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

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