FileBeat收获问题

Question

我们用麋鹿控制我们的程序日志。在我们的FileBeat配置中，我们从获取30种不同的路径，其中包含每秒钟更新一次的文件(它每秒钟更新一次，仅在prod的机器中更新--在其他的机器中，我们的日志要少得多)。我们的日志文件直到它们变老才会被删除，并且我们不再使用它们(而且我们也不会修改它们的名称)。最近，我们发现配置文件(.yml)中的配置文件()中的最后一条路径上的日志来自prod，从未出现在Kibana中。

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

我查阅了关于FileBeat配置的文档，看到了close* options 配置，这似乎是个好主意。但是我还没有把它做好，我也不确定scan_frequency选项的推荐时间是什么(目前这是默认的10s)，以及什么是最好的服务方式。

我试着把close_timeout改为15 s，把close_timeout改为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

.....same如上所示

 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弹性论坛上尝试了我的运气之后。我设法解决了这个问题。

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

显然，File节拍采集系统在同时处理大量打开的文件时有限制。(一个已知的问题和弹性团队还提供了一系列配置选项来帮助处理这个问题，并根据您的需要定制麋鹿，例如选项)。我成功地解决了我的问题，打开了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一直试图操作它们(而不是“卡住”第一个探矿者)。

我用这种方式将收获能力提高了一倍。

在弹性网站上设置讨论：讨论