Filebeat的使用

前言

logstash自己就能夠具備文件數據採集的功能了，爲何還須要在前面加一層filebeat？理由以下：
logstash是使用Java編寫，插件是使用JRuby編寫，對機器的資源要求會比較高，在logstash中作數據的邏輯過濾已經很吃服務器性能了(即logstash 具備filter功能，能過濾分析日誌)。爲了分攤當前服務器cpu資源，因此將使用GO編寫的輕量級的filebeat做爲單獨組件，放在待收集日誌的服務器上使用。

簡單概述

　　最近在瞭解ELK作日誌採集相關的內容，這篇文章主要講解經過filebeat來實現日誌的收集。日誌採集的工具備不少種，如fluentd, flume, logstash,betas等等。首先要知道爲何要使用filebeat呢？由於logstash是jvm跑的，資源消耗比較大，啓動一個logstash就須要消耗500M左右的內存，而filebeat只須要10來M內存資源。經常使用的ELK日誌採集方案中，大部分的作法就是將全部節點的日誌內容經過filebeat送到kafka消息隊列，而後使用logstash集羣讀取消息隊列內容，根據配置文件進行過濾。而後將過濾以後的文件輸送到elasticsearch中，經過kibana去展現。

官網下載地址：https://www.elastic.co/cn/downloads/beats/filebeat

官網配置說明：https://www.elastic.co/guide/en/beats/filebeat/current/configuring-howto-filebeat.html

 

工做原理：

Filebeat能夠保持每一個文件的狀態，而且頻繁地把文件狀態從註冊表裏更新到磁盤。這裏所說的文件狀態是用來記錄上一次Harvster讀取文件時讀取到的位置，以保證能把所有的日誌數據都讀取出來，而後發送給output。若是在某一時刻，做爲output的ElasticSearch或者Logstash變成了不可用，Filebeat將會把最後的文件讀取位置保存下來，直到output從新可用的時候，快速地恢復文件數據的讀取。在Filebaet運行過程當中，每一個Prospector的狀態信息都會保存在內存裏。若是Filebeat出行了重啓，完成重啓以後，會從註冊表文件裏恢復重啓以前的狀態信息，讓FIlebeat繼續從以前已知的位置開始進行數據讀取。

Prospector會爲每個找到的文件保持狀態信息。由於文件能夠進行重命名或者是更改路徑，因此文件名和路徑不足以用來識別文件。對於Filebeat來講，都是經過實現存儲的惟一標識符來判斷文件是否以前已經被採集過。

若是在你的使用場景中，天天會產生大量的新文件，你將會發現Filebeat的註冊表文件會變得很是大。這個時候，你能夠參考（ the section called 「Registry file is too large? edit），來解決這個問題。

 

Filebeat由兩個主要組件組成：prospector 和harvester。這些組件一塊兒工做來讀取文件（tail file）並將事件數據發送到您指定的輸出
啓動Filebeat時，它會啓動一個或多個查找器，查看您爲日誌文件指定的本地路徑。 對於prospector 所在的每一個日誌文件，prospector 啓動harvester。 每一個harvester都會爲新內容讀取單個日誌文件，並將新日誌數據發送到libbeat，後者將聚合事件並將聚合數據發送到您爲Filebeat配置的輸出。

 

harvester(收割機)

harvester :負責讀取單個文件的內容。讀取每一個文件，並將內容發送到 the output
每一個文件啓動一個harvester, harvester 負責打開和關閉文件，這意味着在運行時文件描述符保持打開狀態
若是文件在讀取時被刪除或重命名，Filebeat將繼續讀取文件。
這有反作用，即在harvester關閉以前，磁盤上的空間被保留。默認狀況下，Filebeat將文件保持打開狀態，直到達到close_inactive狀態

關閉harvester會產生如下結果：
1）若是在harvester仍在讀取文件時文件被刪除，則關閉文件句柄，釋放底層資源。
2）文件的採集只會在scan_frequency事後從新開始。
3）若是在harvester關閉的狀況下移動或移除文件，則不會繼續處理文件。

要控制收割機什麼時候關閉，請使用close_ *配置選項

prospector(採礦者)

prospector 負責管理harvester並找到全部要讀取的文件來源。
若是輸入類型爲日誌，則查找器將查找路徑匹配的全部文件，併爲每一個文件啓動一個harvester。
每一個prospector都在本身的Go協程中運行。

如下示例將Filebeat配置爲從與指定的匹配的全部日誌文件中收集行：

filebeat.prospectors:
- type: log paths: - /var/log/*.log - /var/path2/*.log 

Filebeat目前支持兩種prospector類型：log和stdin。
每一個prospector類型能夠定義屢次。
日誌prospector檢查每一個文件以查看harvester是否須要啓動，是否已經運行，
或者該文件是否能夠被忽略（請參閱ignore_older）。
只有在harvester關閉後文件的大小發生了變化，纔會讀取到新行。

注：Filebeat prospector只能讀取本地文件， 沒有功能能夠鏈接到遠程主機來讀取存儲的文件或日誌。

Filebeat如何保持文件的狀態？

Filebeat 保存每一個文件的狀態並常常將狀態刷新到磁盤上的註冊文件中。
該狀態用於記住harvester正在讀取的最後偏移量，並確保發送全部日誌行。
若是輸出（例如Elasticsearch或Logstash）沒法訪問，Filebeat會跟蹤最後發送的行，並在輸出再次可用時繼續讀取文件。
在Filebeat運行時，每一個prospector內存中也會保存的文件狀態信息，
當從新啓動Filebeat時，將使用註冊文件的數據來重建文件狀態，Filebeat將每一個harvester在從保存的最後偏移量繼續讀取。

每一個prospector爲它找到的每一個文件保留一個狀態。
因爲文件能夠被重命名或移動，所以文件名和路徑不足以識別文件。
對於每一個文件，Filebeat存儲惟一標識符以檢測文件是否先前已採集過。

若是您的使用案例涉及天天建立大量新文件，您可能會發現註冊文件增加過大。請參閱註冊表文件太大？編輯有關您能夠設置以解決此問題的配置選項的詳細信息。

Filebeat如何確保至少一次交付

Filebeat保證事件至少會被傳送到配置的輸出一次，而且不會丟失數據。 Filebeat可以實現此行爲，由於它將每一個事件的傳遞狀態存儲在註冊文件中。

在輸出阻塞或未確認全部事件的狀況下，Filebeat將繼續嘗試發送事件，直到接收端確認已收到。

若是Filebeat在發送事件的過程當中關閉，它不會等待輸出確認全部收到事件。
發送到輸出但在Filebeat關閉前未確認的任何事件在從新啓動Filebeat時會再次發送。
這能夠確保每一個事件至少發送一次，但最終會將重複事件發送到輸出。
也能夠經過設置shutdown_timeout選項來配置Filebeat以在關閉以前等待特定時間。

注意：
Filebeat的至少一次交付保證包括日誌輪換和刪除舊文件的限制。若是將日誌文件寫入磁盤而且寫入速度超過Filebeat能夠處理的速度，或者在輸出不可用時刪除了文件，則可能會丟失數據。
在Linux上，Filebeat也可能因inode重用而跳過行。有關inode重用問題的更多詳細信息，請參閱filebeat常見問題解答。

 

示例：Filebeat --> Kafka

filebeat.prospectors:
- type: log
  paths:
    - /home/hottopic/logs/b612/8086/b612.json
    - /home/hottopic/logs/b612/8088/b612.json
  json.keys_under_root: true
  json.overwrite_keys: true
processors:
- drop_fields:
    fields: ["offset","prospector", "tags","beat.name", "beat.version"]
output:
  kafka:
    enabled: true
    hosts: ["172.17.65.210:9092", "172.17.65.211:9092"]
    topic: adsdk
    compression: gzip
    required_acks: 1
    max_message_bytes: 1000000
max_procs: 1