FileBeat 收获问题

我们使用 ELK 来控制我们的程序日志。 在我们的 FileBeat 配置中，我们从中获取30种不同包含每秒更新的文件的路径（它仅在产品机器中每秒更新 - 在其他开发机器中，我们的日志要少得多）。 我们的日志文件不会被删除，直到它们变旧并且我们停止使用它们（我们也不会修改它们的名称）。 最近我们发现配置文件（.yml）中最后一个路径的日志从生产机器从未出现在 Kibana 中。

经过调查，我们意识到 FileBeat 停留在文件上是第一个路径，并且似乎永远不会到达最后一个路径。当我将最后两条路径的位置替换为开头时，FileBeat 开始在那里注册所有日志，然后收集它们。

我查阅了有关 FileBeat 配置的文档，看到了 close* 选项关闭选项配置 https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html#close-options这似乎是个好主意。但我还没有设法把它做好，我不确定 scan_Frequency 选项的建议时间是多少（目前默认为 10 秒）以及什么对我来说是最好的方式。

我试图改变关闭超时到 15 秒和扫描频率 to 2m

      close_timeout: 15s
      scan_frequency: 2m

我想在这里提出一些意见，我能做些什么来解决这个问题？我将配置放在这里是为了提供一些参考，并看看我是否遗漏了其他内容。

我的 filebeat.yml：（更改前）

      filebeat:
  # List of prospectors to fetch data.
  prospectors:
    # Each - is a prospector. Below are the prospector specific configurations
    -
      paths:
        - D:\logs\*\path1\a_*_Pri_app.log.txt
      input_type: log
      document_type: type1
      multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
      multiline.negate: true
      multiline.match: after
    -
      paths:
        - D:\logs\*\path2\b_*_Paths_app.log.txt
      input_type: log
      document_type: type2
      multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
      multiline.negate: true
      multiline.match: after
    -
      paths:
        - D:\logs\*\path3\c_*_R_app.log.txt
      input_type: log
      document_type: path3
      multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
      multiline.negate: true
      multiline.match: after
    -
      paths:
        - D:\logs\*\path4\d_*_d_app.log.txt
        - C:\logs\*\path4\d_*_d_app.log.txt
      input_type: log
      document_type: path4
      multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
      multiline.negate: true
      multiline.match: after

.....同上

 paths:
        - D:\logs\*\path27\S.Coordinator_Z.*.log*
        - C:\logs\*\path27\S.Coordinator_Z*.log*
      input_type: log
      document_type: path27
      multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
      multiline.negate: true
      multiline.match: after
    -
      paths:
        - D:\logs\*\path28\d_*_Tr_app.log.txt
        - C:\logs\*\path28\d_*_Tr_app.log.txt
      input_type: log
      document_type: path28
      multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
      multiline.negate: true
      multiline.match: after
    -
      paths:
        - D:\logs\*\R1_Output\R*\pid_*_rr_*
      input_type: log
      document_type: path29
      multiline.pattern: '<\?xml version="1\.0" encoding="UTF-8"\?>'
      multiline.negate: true
      multiline.match: after  
    -
      paths:
        - D:\logs\*\R2_Output\R*\pid_*_rr_*
      input_type: log
      document_type: path30
      multiline.pattern: '<\?xml version="1\.0" encoding="UTF-8"\?>'
      multiline.negate: true
      multiline.match: after

      registry_file: "C:/ProgramData/filebeat/registry"

经过长时间的调查，当我试图找到与我遇到的类似问题时solution，并在讨论弹性论坛尝试了我的运气之后。 我设法解决了这个问题。

因为我在网上没有看到这个选项，所以我把它放在这里。

Filebeat 收集系统在同时处理大量打开的文件时显然有其限制。 （一个已知的问题和弹性团队还提供了一堆配置选项来帮助处理这个问题并根据您的需要定制 ELK，例如配置选项 https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html#close-options）。 我设法通过打开另外 2 个 Filebeat 服务来解决我的问题，我按以下方式配置它们的探矿者（A 的示例相同到 B）：

paths:
    - D:\logs\*\pid_*_rr_*
  input_type: log
  document_type: A 
  multiline.pattern: '<\?xml version="1\.0" encoding="UTF-8"\?>'
  multiline.negate: true
  multiline.match: after
  close_eof: true

这样，因为相互依赖地工作的服务 Filebeat 不断尝试操作它们（而不是“卡在”第一个探矿者身上）。

我通过这种方式使我的收获能力加倍。

在 Elastic 网站上提出讨论：讨论 https://discuss.elastic.co/t/filebeat-isnt-harvesting-the-logs-from-the-last-paths/106841/7