11同行回答
三种常见日志收集解决方案
1.每个app的镜像中都集成日志收集组件：
优点：
部署方便，kubernetes的yaml文件无须特别配置，可以为每个app自定义日志收集配置
缺点：
强耦合，不方便应用和日志收集组件升级和维护且会导致镜像过大2.单独创建一个日志收集组件跟app的容器一起运行在同一个pod中：
优点：
低耦合，扩展性强，方便维护和升级
缺点：
需要对kubernetes的yaml文件进行单独配置，略显繁琐3：将所有的Pod的日志都挂载到宿主机上，每台主机上单独起一个日志收集Pod：
优点：
完全解耦，性能最高，管理起来最方便
缺点：
需要统一日志收集规则，目录和输出方式
传统架构
在传统架构下日志是落盘后再采集还是直接通过网络发到外部两种方案在业界均有使用。日志落盘后采集可以基于丰富的开源框架统一进行日志采集，整个日志采集完全与业务解耦，并可以独立管理部署，但是对于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集群 ，通过另外的日志服务系统提供日志查询服务；另一方面日志文件持久化到共享存储中，支持通过服务器查看。
收起