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網站中的討論 ： 討論