容器日志集中收集与转发的核心是绕过容器生命周期限制，稳定低开销地将stdout/stderr或日志文件送至统一后端；需区分日志来源类型、选择daemonset/sidecar/日志驱动等部署模式、提取元数据、配置缓冲与可靠传输链路。
容器日志集中收集与转发，核心是绕过单个容器生命周期的限制，把 stdout/stderr 或容器内日志文件，稳定、低开销、可扩展地“搬”到统一后端。关键不在于堆组件，而在于选对路径、配好角色、守住边界。
明确日志来源类型再定采集方式
容器日志不是只有一种形态，采集前必须区分清楚：
-
标准输出日志（推荐首选）：应用直接打印到 stdout/stderr，由容器运行时（Docker/containerd）自动转为 JSON 文件，路径如
/var/log/containers/*.log。这是最轻量、最可靠的方式，kubectl logs能查，采集器也最容易发现和读取。 -
容器内日志文件：应用自行写入
/app/logs/app.log等路径。此时需确保该路径已挂载 hostPath 或 emptyDir，否则容器退出日志即丢失；也可用 sidecar 容器把文件重定向到自己的 stdout，复用标准流采集链路。 -
宿主机本地文件：少量系统级或遗留服务日志落盘在节点上（如
/var/log/nginx/access.log），可由节点级采集器一并纳入。
选择合适的采集部署模式
采集器怎么部署，直接影响稳定性、资源占用和运维粒度：
-
DaemonSet 模式（主流推荐）：在每个节点部署一个 Fluent Bit 或 Filebeat 实例，挂载
/var/log/containers和/var/log/pods目录。优点是资源省、覆盖全、无侵入，适合绝大多数业务场景。 - Sidecar 模式（高隔离需求）：为关键业务 Pod 单独注入一个日志采集容器（如 Promtail 或 Fluentd），只负责本 Pod 日志。适合需要独立配置、过滤、加密或限速的敏感服务。
-
日志驱动直连（简化架构）：启动容器时指定
--log-driver=fluentd或--log-driver=loki，由运行时直接推送日志。适合小规模或测试环境，但耦合度高，故障排查路径变长。
配置采集器提取关键元数据
光把日志文本搬过去不够，必须附带上下文才能查得准、分得清：
- 强制解析时间戳、日志级别（INFO/WARN/ERROR）、容器 ID、Pod 名、命名空间、节点名；
- 通过 tag 或 labels 自动打标，例如
tag kube.${namespace}.${pod_name}，便于 Kibana 或 Grafana 按服务维度筛选； - 识别多行日志（如 Java 异常堆栈），避免被拆成多条记录，Fluent Bit 的
multiline.parser或 Fluentd 的concat插件可解决； - 对敏感字段（如 token、身份证号）做脱敏处理，可在采集器 filter 阶段完成，不传原始内容。
设置缓冲与可靠传输链路
网络抖动、后端临时不可用不能导致日志丢失：
- 采集器启用内存+磁盘双缓冲（如 Fluent Bit 的
Mem_Buf_Limit+storage.type filesystem）； - 传输层建议加一层消息队列（Kafka 或 Redis），解耦采集与存储，应对 Elasticsearch 维护窗口；
- 输出端配置重试机制与死信队列（DLQ），失败日志暂存并告警，避免静默丢弃；
- 监控采集器自身指标：日志延迟（processing latency）、发送成功率、磁盘缓冲水位，用 Prometheus 抓取暴露的 metrics 端点。
