FileBeat收集问题

Question

我们正在使用ELK来控制程序日志。 在我们的FileBeat配置中，我们从30个不同的路径中收获， 这些路径包含每秒更新的文件（它仅在prod的机器中每秒更新一次-在其他Dev机器中，日志大大减少）。 我们的日志文件不会变旧，直到它们变旧为止，我们将停止使用它们（我们也不会在此处修改名称）。 最近，我们发现，来自Prod 机器的配置文件（.yml）中来自最后路径的日志从未出现在Kibana中。

经过调查，我们意识到卡在文件上的FileBeat是第一个路径，似乎从未到达最后一个路径。 当我将最后两个路径的位置替换为开头时，FileBeat开始在此处注册所有日志，并在以后收集它们。

我查阅了有关FileBeat配置的文档，并且看到了close *选项close_option_config似乎是个好主意。 但是我还没有设法弄清楚它，我不确定scan_frequency选项的建议时间是多少（目前默认为10s），什么会以最佳方式为我服务。

我试图将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弹性论坛中尝试了运气。 我设法解决了这个问题。

由于我没有在网络上看到此选项，因此将其放在此处。

当同时处理大量打开的文件时，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相互依赖地工作，因此它们一直试图操作它们（而不是“卡在”第一个探矿者上）。

我以这种方式设法使我的收割能力加倍。

构成Elastic网站中的讨论 ： 讨论