FileBeat 采集问题

Question

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

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

我查阅了有关 FileBeat 配置的文档，我看到了关闭*选项 close_option_config，这似乎是个好主意。但我还没有设法做到正确，我不确定 scan_frequency 选项的推荐时间是多少（目前默认为 10 秒）以及什么能以最好的方式为我服务。

我尝试将 close_timeout 更改为 15s，将 scan_frequency 更改为 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"

Answer 1

经过长时间的调查，当我试图找到与我在 解决方案 中遇到的问题类似的问题时，并在 dicuss elastic 论坛上碰碰运气。我设法解决了这个问题。

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

Filebeat 收集系统在同时处理大量打开的文件时显然有其局限性。（一个已知问题和弹性团队还提供了一堆配置选项来帮助处理这个问题和服装 ELK 以满足您的需要，例如 config_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 的服务相互依赖地工作，所以不断尝试操作它们（而不是 "stuck" 在第一个探矿者上）。

我通过这种方式使我的收割能力翻了一番。

在 Elastic 网站提出讨论： the discussion

FileBeat 采集问题

FileBeat harvesting issues

yaml

elasticsearch

elastic-stack

filebeat