Filebeat container输入与带container解析器的filestream输入差异

你贴的两种配置并不完全等价，在Filebeat 8.3版本下二者核心的容器日志读取目标路径一致，但底层实现、默认解析行为、长期支持属性存在明显差异。 #

底层实现逻辑不同 #

• type: container是早期版本推出的专用容器日志输入，底层基于已经进入淘汰周期的旧版log采集引擎实现，容器日志解析、元数据关联的逻辑是硬编码在输入模块内部的，扩展性差。
• filestream + container parser的组合基于官方新一代filestream采集引擎实现，容器格式解析只是作为可插拔的解析器挂载到采集链路上，引擎本身负责文件发现、读取、断点续传，和解析逻辑完全解耦。

你贴出的两份配置示例如下：

1. 原生container输入配置

filebeat.inputs:
- type: container
  paths:
    - '/var/lib/docker/containers/*/*.log'

2. filestream挂载container解析器配置

filebeat.inputs:
- type: filestream
  id: my-id
  paths:
    - '/var/lib/docker/containers/*/*.log'
  parsers:
    - container:

默认行为存在差异 #

• 原生type: container默认内置了一整套固定的容器日志处理规则：自动识别docker JSON日志格式、拆分stdout/stderr标记、默认适配容器日志的多行匹配规则、自动附加基础容器元数据，不需要额外配置参数即可输出标准化的容器日志字段。
• 你贴的极简版filestream + container parser配置，默认仅做最基础的日志行前缀拆分（剥离docker日志行自带的时间戳、流标记），不会自动开启多行合并、JSON字段全解析、元数据附加逻辑，如果直接上线使用，输出的字段结构和原生container输入有明显区别，需要手动补全对应parser参数才能对齐行为。

生命周期定位不同 #

从Filebeat 7.14版本正式推出filestream输入开始，官方就已经停止给旧版log、container输入追加新功能，仅保留高危bug修复，后续所有性能优化、新特性迭代都会全部集中在filestream输入线上，旧输入类型会在未来版本正式废弃。 #

• 全新部署的采集链路优先选择filestream + container parser方案。8.3版本下filestream的容器解析能力已经生产可用，相比旧container输入有明确优势：高并发日志采集时资源占用更低、容器重建/日志轮转场景下断点续传准确率更高、解析规则可以灵活组合（支持在container解析前后插入多行处理、脱敏、截断等自定义逻辑）。注意不要直接使用你贴的空配置，需要根据业务需求显式配置container parser的参数、补充需要的其他解析规则、配置docker元数据关联选项，对齐你需要的输出字段结构。
• 存量已经稳定运行的type: container采集链路，如果已经和下游索引、告警、看板规则深度绑定，8.3版本下可以继续使用，不需要强制立即迁移，但要在后续版本升级前提前完成filestream方案的适配测试，避免旧输入废弃后出现兼容问题。

内容的提问来源于stack exchange，提问作者Chad Showalter