filebeat 容器输入和带有容器解析器的 filebeat 文件流输入有什么区别？

Question

我注意到 filebeat documentation 表明文件流输入是日志输入的新的和改进的替代方案。我还注意到文档表明容器解析器可以指定为文件流输入配置的子项。例如，文件流输入：

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

对

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

这些是等价的吗？为什么我会选择其中之一而不是另一个？

我在 Docker 容器中使用 filebeat 8.3（截至本文的当前版本）。

Answer 1

当前 Elastic Stack 版本为 8.12 时编写

log

输入已被弃用并将被删除，新奇的

filestream

输入已取代它。这是唯一简单的部分。

container

包裹

log

，添加

format

和

stream

选项。
来自

container

的 文档：
此输入在给定路径下搜索容器日志，并将它们解析为公共消息行，并提取时间戳。一切都发生在行过滤、多行和 JSON 解码之前，因此此输入可以与这些设置结合使用。

自从

log

死后，容器的命运正在被积极讨论 这里。

有一个container_v2的

草稿

，它将包裹

filestream

，并包含

stream

和

format

选项，我不明白，似乎只是为了方便迁移？

stream

和

format

选项形式的专业已经存在于

filestream

的解析器选项中，所以我不明白为什么如果你要开始一个新的，你会使用

container

记录。
甚至自动发现也从container

切换到

filestream

。

TL;DR 和方便的

迁移指南

在新部署中使用
• filestream

   而非 

  log

  /

  container
对于旧的
• container

   部署，您可能希望迁移到 

  filestream
对于旧的
• log

   部署，您绝对希望迁移到 

  filestream

  ，因为它已被弃用