Filebeat是本地文件的日志數據采集器，可監控日志目錄或特定日志文件（tail file），並將它們轉發給Elasticsearch或Logstatsh進行索引、kafka等。帶有內部模塊（auditd，Apache，Nginx，System和MySQL），可通過一個指定命令來簡化通用日志格式的收集，解析和可視化。
官方網址:https://www.elastic.co/guide/en/beats/filebeat/current/index.html
1.工作原理
Filebeat涉及兩個組件：查找器prospector和采集器harvester，來讀取文件(tail file)並將事件數據發送到指定的輸出。
啟動Filebeat時，它會啟動一個或多個查找器，查看你為日志文件指定的本地路徑。對於prospector所在的每個日志文件，prospector啟動harvester。每個harvester都會為新內容讀取單個日志文件，並將新日志數據發送到libbeat，后者將聚合事件並將聚合數據發送到你為Filebeat配置的輸出。
當發送數據到Logstash或Elasticsearch時，Filebeat使用一個反壓力敏感(backpressure-sensitive)的協議來解釋高負荷的數據量。當Logstash數據處理繁忙時，Filebeat放慢它的讀取速度。一旦壓力解除，Filebeat將恢復到原來的速度，繼續傳輸數據。
1.1采集器Harvester
Harvester負責讀取單個文件的內容。讀取每個文件，並將內容發送到the output，每個文件啟動一個harvester, harvester負責打開和關閉文件，這意味着在運行時文件描述符保持打開狀態。
如果文件在讀取時被刪除或重命名，Filebeat將繼續讀取文件。這有副作用，即在harvester關閉之前，磁盤上的空間被保留。默認情況下，Filebeat將文件保持打開狀態，直到達到close_inactive狀態
關閉harvester會產生以下結果：
1）如果在harvester仍在讀取文件時文件被刪除，則關閉文件句柄，釋放底層資源。
2）文件的采集只會在scan_frequency過后重新開始。
3）如果在harvester關閉的情況下移動或移除文件，則不會繼續處理文件。
要控制收割機何時關閉，請使用close_ *配置選項
1.2查找器Prospector
Prospector負責管理harvester並找到所有要讀取的文件來源。如果輸入類型為日志，則查找器將查找路徑匹配的所有文件，並為每個文件啟動一個harvester。每個prospector都在自己的Go協程中運行。
Filebeat目前支持兩種prospector類型：log和stdin。每個prospector類型可以定義多次。日志prospector檢查每個文件來查看harvester是否需要啟動，是否已經運行，或者該文件是否可以被忽略（請參閱ignore_older）。
只有在harvester關閉后文件的大小發生了變化，才會讀取到新行。
注：Filebeat prospector只能讀取本地文件，沒有功能可以連接到遠程主機來讀取存儲的文件或日志。
2.配置文件
配置文件：$FILEBEAT_HOME/filebeat.yml。Filebeat可以一次讀取某個文件夾下的所有后綴名為log的文件，也可以讀取指定的某一個后綴名為log的文件。
配置文件詳解（http://blog.51cto.com/michaelkang/1864225）
（1）字段解釋
paths：指定要監控的日志，目前按照Go語言的glob函數處理。沒有對配置目錄做遞歸處理，比如配置的如果是：
/var/log/* /*.log
則只會去/var/log目錄的所有子目錄中尋找以".log"結尾的文件，而不會尋找/var/log目錄下以".log"結尾的文件。
encoding：指定被監控的文件的編碼類型，使用plain和utf-8都是可以處理中文日志的。
input_type：指定文件的輸入類型log(默認)或者stdin。
exclude_lines：在輸入中排除符合正則表達式列表的那些行。
include_lines：包含輸入中符合正則表達式列表的那些行（默認包含所有行），include_lines執行完畢之后會執行exclude_lines。
exclude_files：忽略掉符合正則表達式列表的文件（默認為每一個符合paths定義的文件都創建一個harvester）。
fields：向輸出的每一條日志添加額外的信息，比如"level:debug"，方便后續對日志進行分組統計。默認情況下，會在輸出信息的fields子目錄下以指定的新增fields建立子目錄，
fields_under_root：如果該選項設置為true，則新增fields成為頂級目錄，而不是將其放在fields目錄下。自定義的field會覆蓋filebeat默認的field。
ignore_older：可以指定Filebeat忽略指定時間段以外修改的日志內容，比如2h（兩個小時）或者5m(5分鍾)。
close_older：如果一個文件在某個時間段內沒有發生過更新，則關閉監控的文件handle。默認1h。
force_close_files：Filebeat會在沒有到達close_older之前一直保持文件的handle，如果在這個時間窗內刪除文件會有問題，所以可以把force_close_files設置為true，只要filebeat檢測到文件名字發生變化，就會關掉這個handle。
scan_frequency：Filebeat以多快的頻率去prospector指定的目錄下面檢測文件更新（比如是否有新增文件），如果設置為0s，則Filebeat會盡可能快地感知更新（占用的CPU會變高）。默認是10s。
document_type：設定Elasticsearch輸出時的document的type字段，也可以用來給日志進行分類。
harvester_buffer_size：每個harvester監控文件時，使用的buffer的大小。
max_bytes：日志文件中增加一行算一個日志事件，max_bytes限制在一次日志事件中最多上傳的字節數，多出的字節會被丟棄。默認是10MB。
multiline：適用於日志中每一條日志占據多行的情況，比如各種語言的報錯信息調用棧。這個配置的下面包含如下配置：
pattern：多行日志開始的那一行匹配的pattern
negate：是否需要對pattern條件轉置使用，不翻轉設為true，反轉設置為false。
match：匹配pattern后，與前面（before）還是后面（after）的內容合並為一條日志
max_lines：合並的最多行數（包含匹配pattern的那一行），默認為500行。
timeout：到了timeout之后，即使沒有匹配一個新的pattern（發生一個新的事件），也把已經匹配的日志事件發送出去
tail_files：如果設置為true，Filebeat從文件尾開始監控文件新增內容，把新增的每一行文件作為一個事件依次發送，而不是從文件開始處重新發送所有內容。
backoff：Filebeat檢測到某個文件到了EOF之后，每次等待多久再去檢測文件是否有更新，默認為1s。
max_backoff：Filebeat檢測到某個文件到了EOF之后，等待檢測文件更新的最大時間，默認是10秒。
backoff_factor：定義到達max_backoff的速度，默認因子是2，到達max_backoff后，變成每次等待max_backoff那么長的時間才backoff一次，直到文件有更新才會重置為backoff。比如：
如果設置成1，意味着去使能了退避算法，每隔backoff那么長的時間退避一次。
spool_size:spooler的大小，spooler中的事件數量超過這個閾值的時候會清空發送出去（不論是否到達超時時間），默認1MB。
idle_timeout:spooler的超時時間，如果到了超時時間，spooler也會清空發送出去（不論是否到達容量的閾值），默認1s。
registry_file:記錄filebeat處理日志文件的位置的文件
config_dir:如果要在本配置文件中引入其他位置的配置文件，可以寫在這里（需要寫完整路徑），但是只處理prospector的部分。
publish_async：是否采用異步發送模式（實驗功能）。
具體的一個yml采集配置樣例如下：該配置文件是filebeat采集數據的依據，並根據需求添加必要配置，filebeat收集日志后發往logstash，配置如下：
3.啟動和停止
3.1開啟filebeat
cd FILEBEAT_HOME
nohup ./bin/filebeat -f config/test.conf >>/FILEBEAT_HOME/logs/filebeat.log &
后台啟動filebeat，配置對應的參數
啟動多個filebeat配置，新建一個目錄（conf）存放多個filebeat的配置文件，
#nohup ./bin/filebeat -f conf/* >>/FILEBEAT_HOME/logs/filebeat.log &
注意：一台服務器只能啟動一個filebeat進程。
3.2停止filebeat
ps -ef |grep filebeat
kill -9 $pid
注意： 非緊急情況下，殺掉進程只能用優雅方式。
3.3filebeat運行可能存在的問題（運行前最好是輸出到控制台查看）
A、filebeat運行不成功
問題：配置文件格式有問題，配置文件遵循yml文件格式，多或少一個空格都會導致啟動問題，可以使用cmd命令窗口到filebeat安裝路徑下，使用filebeat.exe –c filebeat.yml 查看報錯，也可以看filebeat路徑下的log文件夾中的filebeat文件
B、 filebeat第一次運行成功無數據
問題：a、路徑有問題
b、運行條件設置有問題（例如只采集某個條件下的數據，文件中沒有符合條件的數據，這種情況下先注釋掉采集條件測試一下）
C、filebeat運行成功第一次運行后有數據，第二次無數據
問題：filebeat讀取文件后會生成一個registry文件，注意windows機器中這個文件在手動啟動的情況下會在filebeat安裝目錄下的data文件夾中，服務注冊啟動的情況下會在C盤下隱藏文件夾C:\ProgramData\filebeat中，刪除掉這個就可以了
D、filebeat運行成功有數據，但是新添加數據不讀取問題
問題：filebeat傳輸存在反壓機制，在數據量特別大或者傳輸通道不通的情況下，filebeat會進行反壓，暫停發送，等到數據量穩定或者數據傳輸通道正常的之后才會發送
4.注意問題
4.1Filebeat如何保持文件的狀態？
Filebeat 保存每個文件的狀態並經常將狀態刷新到磁盤上的注冊文件中。該狀態用於記住harvester正在讀取的最后偏移量，並確保發送所有日志行。如果輸出（例如Elasticsearch或Logstash）無法訪問，Filebeat會跟蹤最后發送的行，並在輸出再次可用時繼續讀取文件。
在Filebeat運行時，每個prospector內存中也會保存文件狀態信息，當重新啟動Filebeat時，將使用注冊文件的數據來重建文件狀態，Filebeat將每個harvester在從保存的最后偏移量繼續讀取。
每個prospector為它找到的每個文件保留一個狀態。由於文件可以被重命名或移動，因此文件名和路徑不足以識別文件。對於每個文件，Filebeat存儲唯一標識符以檢測文件是否先前已被采集過。
如果你使用的案例涉及每天創建大量新文件，你可能會發現注冊文件增長過大。請參閱注冊表文件太大？編輯有關你可以設置以解決此問題的配置選項的詳細信息。
4.2Filebeat如何確保至少一次交付？
Filebeat保證事件至少會被傳送到配置的輸出一次，並且不會丟失數據。 Filebeat能夠實現此行為，因為它將每個事件的傳遞狀態存儲在注冊文件中。
在輸出阻塞或未確認所有事件的情況下，Filebeat將繼續嘗試發送事件，直到接收端確認已收到。如果Filebeat在發送事件的過程中關閉，它不會等待輸出確認所有收到事件。
發送到輸出但在Filebeat關閉前未確認的任何事件在重新啟動Filebeat時會再次發送。這可以確保每個事件至少發送一次，但最終會將重復事件發送到輸出。
也可以通過設置shutdown_timeout選項來配置Filebeat以在關閉之前等待特定時間。
注意：Filebeat的至少一次交付保證包括日志輪換和刪除舊文件的限制。如果將日志文件寫入磁盤並且寫入速度超過Filebeat可以處理的速度，或者在輸出不可用時刪除了文件，則可能會丟失數據。
在Linux上，Filebeat也可能因inode重用而跳過行。有關inode重用問題的更多詳細信息，請參閱filebeat常見問題解答。
4.3Filebeat如何保證在日志文件被切割(或滾動rolling)時依然正確讀取文件？
Logback日志切割用的是JDK里File#renameTo()方法。如果該方法失敗，就再嘗試使用復制數據的方式切割日志。查找該方法相關資料得知，只有當源文件和目標目錄處於同一個文件系統、同volumn(即windows下的C, D盤)下該方法才會成功，切不會為重命名的后的文件分配新的inode值。也就是說，如果程序里一直保存着該文件的描述符，那么當程序再寫日志時，就會向重命名后的文件中寫。那么問題來了，filebeat是會一直打開並保存文件描述符的，那么它是怎么得知日志被切割這件事的呢？
如果只用當前文件描述符一路監控到天黑的話，那么當logback把日志重命名后，filebeat仍然會監控重命名后的日志，新創建的日志文件就看不到了。實際上，filebeat是通過close_inactive和scan_frequency兩個參數(機制)來應對這種情況的：
(1)close_inactive
該參數指定當被監控的文件多長時間沒有變化后就關閉文件句柄(file handle)。官方建議將這個參數設置為一個比文件最大更新間隔大的值。比如文件最長5s更新一次，那就設置成1min。默認值為5min。
(2)scan_frequency
該參數指定Filebeat搜索新文件的頻率(時間間隔)。當發現新的文件被創建時， Filebeat會為它再啟動一個 harvester 進行監控，默認為10s。
綜合以上兩個機制，當logback完成日志切割后(即重命名)，此時老的harvester仍然在監控重命名后的日志文件，但是由於該文件不會再更新，因此會在close_inactive時間后關閉這個文件的 harvester。當scan_frequency時間過后，Filebeat會發現目錄中出現了新文件，於是為該文件啟動 harvester 進行監控。這樣就保證了切割日志時也能不丟不重的傳輸數據。(不重是通過為每個日志文件保存offset實現的)
鏈接：https://www.jianshu.com/p/0a5acf831409
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
喜歡這篇文章？歡迎打賞~~
