容器日志方案选边车采集还是守护进程，核心差别在于：守护进程是节点级共享采集，省资源、好运维，但隔离性差；边车是每个 Pod 独占采集，稳定性和多租户隔离更好，代价是资源占用明显上浮。 如果你还没有明确需求，先记住一句话：小集群单团队用守护进程，多团队大集群，或者对日志链路稳定性要求很高的场景，优先考虑边车。
自建K8s日志采集方案对比：边车和守护进程差别怎么理解
先解释两个模式到底在干什么。
守护进程采集,是在每个节点上跑一个 DaemonSet 采集器，filebeat、fluent-bit，它直接读取节点上 /var/log/containers 目录下的容器日志文件，所有 Pod 的日志都交给这一个进程统一收集，再转发到 Kafka、Elasticsearch 或 ClickHouse，部署上很简洁，一个 DaemonSet 资源搞定全集群。
边车采集,是在每个需要采集日志的 Pod 里额外塞一个采集容器，和业务容器共享同一个 emptyDir 卷，业务容器把日志写进文件，边车把文件内容读出来发往下游，一个 Pod 一个采集器，链路互相独立，互不相干。
从架构上看,两者真正的区别在于“共享”和“独占”，守护进程赌的是节点上所有日志加在一起不超过采集器的处理能力；边车赌的是单个业务容器的日志量不会压垮自己。
守护进程采集容器日志的优势和限制
守护进程模式最明显的优势是成本和运维。
- 每个节点只跑一个采集进程,资源消耗小，管理对象少
- 新增节点时 DaemonSet 自动铺好采集器，不需要额外操作
- 通过读取
/var/log/containers下的软链接，能直接拿到 Pod 的元数据，不用改业务代码
大多数中小型集群,日志量平稳，下游存储带宽够用，守护进程是最务实的选择，但它的短板也很清晰。
第一个短板是突发流量下容易丢日志,一个节点上几十个 Pod 的日志都灌进同一个采集器，采集器的内存 queue 会被顶高，一旦下游 Kafka 或者 ES 响应变慢，queue 排满，采集器就会丢弃新到的日志，而且这个丢弃过程是静默的，不报错，不重试，下游收到的日志出现断档，排查时才发现时间线有缺口。
第二个短板是故障扩散,所有 Pod 的日志在同一个采集进程里处理，只要其中一个 Pod 疯狂打错日志，把采集器的 CPU 打满，同节点上其他 Pod 的日志采集全部跟着变慢甚至停摆，业务之间本没有直接关联，日志采集却被强行绑在了一起。
第三个短板是配置调整不灵活,有的应用输出 JSON，有的应用输出多行堆栈，有的应用日志按天滚动，守护进程模式下只能靠全局 parser 和 filter 去兼容，想针对某个工作负载做单独的多行合并规则或输出目标，配置会变得非常绕。
边车日志采集优缺点：用资源换稳定性和隔离
边车模式近年来越来越多被提及,跟 Istio 普及有一定关系，但日志边车比流量边车出现得更早，实现也更简单。
边车采集的优点,正好打在了守护进程的痛点上。
- 采集进程和业务容器同生命周期,Pod 启动采集器就在，Pod 销毁采集器跟着退出，不会出现节点级采集器挂掉但业务还在运行的“裸奔”状态
- 每个应用可以设置独立的采集路径、多行合并规则、输出目标，互不干扰
- 缓存和队列都隔离在 Pod 内部，某个 Pod 日志量再大，也只是拖垮自己的边车，影响不到邻居
- 支持按工作负载直连不同的下游,A 应用发到 ES，B 应用发到 Kafka，不用经过统一的日志汇聚层
代价也摆在那里。
资源占用是边车绕不开的成本,每多一个边车容器，就多一份 CPU 和内存配额，以 fluent-bit 为例，默认配置下单个容器大约占用几十毫核 CPU 和几十 MiB 内存，看起来不大，但集群里如果跑了几百个 Pod，累计起来就是一笔非常大的资源开销，放在云上按核时计费的话，边车模式的资源账单会比守护进程模式高出不少，具体多花多少，取决于 Pod 总量和日志写入量。
边车读取的是 emptyDir，默认落在节点磁盘上，业务容器写日志和边车容器读日志共用同一个磁盘 IO，写入量大时，业务容器的写延迟会受影响，这一点在做容量评估时经常被忽略。
运维上也更繁琐,每个应用的部署模板里都要嵌入一段边车配置，镜像升级和配置变更要逐个工作负载处理，不像守护进程改一个 DaemonSet 就全局生效。
边车日志采集适合什么场景
适合边车的场景,通常逃不开两个特征：一是日志不能丢，二是团队和租户界限分明。
任务型负载是边车的高频应用场景,Spark 作业、批处理容器，跑完就退出，守护进程采集很容易漏掉容器退出前最后一段日志，在 Pod 里挂一个边车，作业跑完边车跟着退出，日志完整地发往了下游，不少做离线计算的团队就是这么干的，比事后从节点上捞容器文件省事得多。
另一个是合规和多租户场景,金融、政务客户对日志的租户隔离有明确要求，守护进程模式下所有租户的日志经过同一个采集器，审计上说不清楚，日志采集 sidecar 模式多租户隔离的优势在这里很突出，每个租户的日志由各自的边车直发到各自的存储桶，链路里不存在交叉，审计追查起来脉络清晰。
容器日志采集选型：守护进程和边车到底怎么挑
判断标准可以压缩成三条。
第一条,有没有审计或合规要求？有，直接选边车，第二条，日志量是否经常出现单节点突发，而且下游时不时有抖动？是，守护进程的静默丢日志会让人很被动，建议关键链路换边车，第三条，成本预算能不能覆盖边车带来的额外资源开销？如果预算紧张，且日志链路允许一定比例的丢失，守护进程是更现实的选择。
用一张表看差别会更直观：
| 对比维度 | 守护进程模式 | 边车模式 |
|---|---|---|
| 部署方式 | 每个节点一个采集器 | 每个 Pod 一个采集器 |
| 资源占用 | 随节点数线性增长 | 随 Pod 数增长，整体明显偏高 |
| 配置粒度 | 全局统一 | 按工作负载独立配置 |
| 故障隔离 | 节点级共享，会互相影响 | Pod 级隔离，互不干扰 |
| 多租户支持 | 弱 | 强 |
| 运维成本 | 低 | 高 |
| 适用场景 | 中小规模、日志量平稳 | 大集群、多团队、链路要求高 |
这里没有标准答案,只有取舍，行业共识认为，日志采集器的处理能力要留出余量，无论是哪种模式，都应该把采集器的输出队列控制在合理范围，而不是无限加大缓冲，曾有一个日活较大的业务，采用守护进程模式时高峰期经常出现日志断档，核心链路改成边车后链路稳定了，但资源账单也随之涨了一截，这个成本涨幅需要在选型前想清楚。
日志采集落地实操：两种模式怎么配
守护进程模式的推荐配置路径：
- 采集器选 fluent-bit 或 vector，filebeat 也可以，但要控制内部队列大小
- 给采集器设置独立的
requests和limits，不要用默认值，至少预留 200m CPU 和 256Mi 内存 - 用
hostPath挂载/var/log/containers和/var/log/pods，注意以只读方式挂载 - 通过
fieldRef获取NODE_NAME环境变量，打上节点标签，方便下游按节点过滤 - 输出端配置
retry和
backoff
边车模式的推荐配置路径：
- 准备 fluent-bit 官方镜像作为边车容器
- 在 Pod 的
spec中定义emptyDir卷，同时挂载到业务容器和边车容器 - 业务应用把日志写到约定目录,边车容器配置为
tail模式读取该目录 - 边车容器资源不要设置过高,避免单 Pod 资源浪费，建议
limits控制在默认值两倍以内 - 多行日志如 Java 堆栈，必须在 parser 里启用
multiline规则，否则一整段报错会被拆成多条记录 - 修改边车配置时,在 ConfigMap 的配置里加一个版本号环境变量，强制 Pod 重建时加载新配置
几个容易忽略的细节
日志采集时务必保留原始时间戳,很多采集器默认会用采集时间覆盖日志时间，排查线上问题时会直接误导方向，JSON 日志解析后不要丢弃原始字段，保留完整原始内容方便事后回溯，采集器自身的运行日志不要和业务日志混在同一个输出流里，否则下游索引会被污染，检索时混入大量无效数据。
说到底，容器日志方案选边车采集还是守护进程，就是拿资源换稳定和隔离。 如果你的语境是“一个集群、一个团队、日志链路能容忍少量丢失”，守护进程是最省心的起点，如果你的语境是“多租户、多团队、日志一条都不能少”，边车的额外成本是值得的，先想清楚你的日志丢不丢得起，再决定架构怎么走。
Q&A：容器日志采集方案常见问题
守护进程采集容器日志的优势主要体现在哪些方面？
主要在于部署简单、资源占用低、运维成本小，一个 DaemonSet 就可以覆盖整个集群，新增节点自动生效，不需要逐个工作负载配置，对中小规模集群来说是最经济的选择。
多团队共用集群时，日志采集 sidecar 模式多租户隔离好在哪里？
每个团队的工作负载各自挂载独立的边车容器，日志采集链路与其他 Pod 完全分隔，不会出现跨团队日志混采、互相影响的问题，输出端也可以各自指向不同的下游存储系统，审计上更清晰，资源账单也能按团队拆分。
两种模式可以混用吗？
可以，实际场景中，有相当比例的团队用守护进程采集集群系统组件和通用应用的日志，同时用边车采集关键业务链路的日志，判断标准就是看链路重要性，关键链路用边车兜底，非关键链路用守护进程统一管理。