Filebeat複製事件

我正在使用基本麋鹿堆棧設置Filebeat> logstash> elasticsearch> kibana - 所有在5.2版本Filebeat複製事件

當我刪除Filebeat和配置logstash直接在文件看，它攝取正確的號碼的事件。

如果我刪除的數據，並使用Filebeat通過同一個日誌文件的內容logstash重新提取相應的文件，我得到創造了超過10％的事件。我檢查了其中的一些確認重複項是由filebeat創建的。

有沒有人見過這個問題？或者有任何建議，爲什麼會發生？

來源

2017-02-02 N31lR

只要是明確的，是「10％以上的事件」比logstash創建，或「10％以上的活動」不是在源文件中存在嗎？ –

我需要了解首先通過刪除文件擊敗你是什麼意思！

可能性-1

，如果你已經卸載並重新安裝，那麼很明顯文件的節拍將讀取路徑再次數據（你已經重新攝入，並張貼到logstash-> elasticsearch-> kibana（假設舊的數據沒有從彈性節點因此重複刪除）。

可能性-2。

你剛纔已經停止filebeat，配置爲logstash和filebeat重新啓動，可能是你的註冊表文件沒有被正確地更新在關機期間（如您所知，文件節拍逐行讀取並更新註冊表文件e直到它已成功發佈到logstash/elasticsearch/kafka等的哪一行，並且如果這些輸出服務器中的任何一個面臨任何難以處理來自filebeat的巨大輸入負載，則filebeat會等待，直到這些服務器可用於進一步處理輸入數據。一旦輸出服務器可用，filebeat讀取註冊表文件並掃描它已發佈的行並開始發佈下一行）。

樣品註冊表文件會像

{ 
"source": "/var/log/sample/sample.log", 
"offset": 88, 
"FileStateOS": { 
    "inode": 243271678, 
    "device": 51714 
}, 
"timestamp": "2017-02-03T06:22:36.688837822-05:00", 
"ttl": -2 
}

正如你所看到的，它在註冊表文件維護時間戳。所以這是重複的原因之一。

如需進一步參考，可以在下面跟隨鏈接

https://discuss.elastic.co/t/filebeat-sending-old-logs-on-restart/46189 https://discuss.elastic.co/t/deleting-filebeat-registry-file/46112

https://discuss.elastic.co/t/filebeat-stop-cleaning-registry/58902

希望有所幫助。

來源

2017-02-03 14:05:06 RIPAN

Filebeat複製事件

回答

相關問題