詳解日誌採集工具--Logstash、Filebeat、Fluentd、Logagent對比

常見的日誌採集工具備Logstash、Filebeat、Fluentd、Logagent、rsyslog等等，那麼他們之間有什麼區別呢?什麼狀況下咱們應該用哪種工具?

Logstash

Logstash是一個開源數據收集引擎，具備實時管道功能。Logstash能夠動態地未來自不一樣數據源的數據統一塊兒來，並將數據標準化到你所選擇的目的地。

優點

Logstash 主要的有點就是它的靈活性，主要由於它有不少插件，詳細的文檔以及直白的配置格式讓它能夠在多種場景下應用。咱們基本上能夠在網上找到不少資源，幾乎能夠處理任何問題。

劣勢

Logstash 致命的問題是它的性能以及資源消耗(默認的堆大小是 1GB)。儘管它的性能在近幾年已經有很大提高，與它的替代者們相比仍是要慢不少的。這裏有 Logstash 與 rsyslog 性能對比以及Logstash 與 filebeat 的性能對比。它在大數據量的狀況下會是個問題。

另外一個問題是它目前不支持緩存，目前的典型替代方案是將 Redis 或 Kafka 做爲中心緩衝池：

典型應用場景

由於 Logstash 自身的靈活性以及網絡上豐富的資料，Logstash 適用於原型驗證階段使用，或者解析很是的複雜的時候。在不考慮服務器資源的狀況下，若是服務器的性能足夠好，咱們也能夠爲每臺服務器安裝 Logstash 。咱們也不須要使用緩衝，由於文件自身就有緩衝的行爲，而 Logstash 也會記住上次處理的位置。

若是服務器性能較差，並不推薦爲每一個服務器安裝 Logstash ，這樣就須要一個輕量的日誌傳輸工具，將數據從服務器端經由一個或多個 Logstash 中心服務器傳輸到 Elasticsearch：

隨着日誌項目的推動，可能會由於性能或代價的問題，須要調整日誌傳輸的方式(log shipper)。當判斷 Logstash 的性能是否足夠好時，重要的是對吞吐量的需求有着準確的估計，這也決定了須要爲 Logstash 投入多少硬件資源。

Filebeat

做爲 Beats 家族的一員，Filebeat 是一個輕量級的日誌傳輸工具，它的存在正彌補了 Logstash 的缺點：Filebeat 做爲一個輕量級的日誌傳輸工具能夠將日誌推送到中心 Logstash。

在版本 5.x 中，Elasticsearch 具備解析的能力(像 Logstash 過濾器)— Ingest。這也就意味着能夠將數據直接用 Filebeat 推送到 Elasticsearch，並讓 Elasticsearch 既作解析的事情，又作存儲的事情。也不須要使用緩衝，由於 Filebeat 也會和 Logstash 同樣記住上次讀取的偏移，若是須要緩衝(例如，不但願將日誌服務器的文件系統填滿)，可使用 Redis/Kafka，由於 Filebeat 能夠與它們進行通訊。

優點

Filebeat 只是一個二進制文件沒有任何依賴。它佔用資源極少，儘管它還十分年輕，正式由於它簡單，因此幾乎沒有什麼能夠出錯的地方，因此它的可靠性仍是很高的。它也爲咱們提供了不少能夠調節的點，例如：它以何種方式搜索新的文件，以及當文件有一段時間沒有發生變化時，什麼時候選擇關閉文件句柄。

劣勢

Filebeat 的應用範圍十分有限，因此在某些場景下咱們會碰到問題。例如，若是使用 Logstash 做爲下游管道，咱們一樣會遇到性能問題。正由於如此，Filebeat 的範圍在擴大。開始時，它只能將日誌發送到 Logstash 和 Elasticsearch，而如今它能夠將日誌發送給 Kafka 和 Redis，在 5.x 版本中，它還具有過濾的能力。

典型應用場景

Filebeat 在解決某些特定的問題時：日誌存於文件，咱們但願將日誌直接傳輸存儲到 Elasticsearch。這僅在咱們只是抓去(grep)它們或者日誌是存於 JSON 格式(Filebeat 能夠解析 JSON)。或者若是打算使用 Elasticsearch 的 Ingest 功能對日誌進行解析和豐富。

將日誌發送到 Kafka/Redis。因此另一個傳輸工具(例如，Logstash 或自定義的 Kafka 消費者)能夠進一步豐富和轉發。這裏假設選擇的下游傳輸工具可以知足咱們對功能和性能的要求。

Fluentd

Fluentd 建立的初衷主要是儘量的使用 JSON 做爲日誌輸出，因此傳輸工具及其下游的傳輸線不須要猜想子字符串裏面各個字段的類型。這樣，它爲幾乎全部的語言都提供庫，這也意味着，咱們能夠將它插入到咱們自定義的程序中。

優點

和多數 Logstash 插件同樣，Fluentd 插件是用 Ruby 語言開發的很是易於編寫維護。因此它數量不少，幾乎全部的源和目標存儲都有插件(各個插件的成熟度也不太同樣)。這也意味這咱們能夠用 Fluentd 來串聯全部的東西。

劣勢

由於在多數應用場景下，咱們會經過 Fluentd 獲得結構化的數據，它的靈活性並很差。可是咱們仍然能夠經過正則表達式，來解析非結構化的數據。儘管，性能在大多數場景下都很好，但它並非最好的，和 syslog-ng 同樣，它的緩衝只存在與輸出端，單線程核心以及 Ruby GIL 實現的插件意味着它大的節點下性能是受限的，不過，它的資源消耗在大多數場景下是能夠接受的。對於小的或者嵌入式的設備，可能須要看看 Fluent Bit，它和 Fluentd 的關係與 Filebeat 和 Logstash 之間的關係相似。

典型應用場景

Fluentd 在日誌的數據源和目標存儲各類各樣時很是合適，由於它有不少插件。並且，若是大多數數據源都是自定義的應用，因此能夠發現用 fluentd 的庫要比將日誌庫與其餘傳輸工具結合起來要容易不少。特別是在咱們的應用是多種語言編寫的時候，即咱們使用了多種日誌庫，日誌的行爲也不太同樣。

Logagent

Logagent 是 Sematext 提供的傳輸工具，它用來將日誌傳輸到 Logsene(一個基於 SaaS 平臺的 Elasticsearch API)，由於 Logsene 會暴露 Elasticsearch API，因此 Logagent 能夠很容易將數據推送到 Elasticsearch 。

優點

能夠獲取 /var/log 下的全部信息，解析各類格式(Elasticsearch，Solr，MongoDB，Apache HTTPD等等)，它能夠掩蓋敏感的數據信息，例如，我的驗證信息(PII)，出生年月日，信用卡號碼，等等。它還能夠基於 IP 作 GeoIP 豐富地理位置信息(例如，access logs)。一樣，它輕量又快速，能夠將其置入任何日誌塊中。在新的 2.0 版本中，它以第三方 node.js 模塊化方式增長了支持對輸入輸出的處理插件。重要的是 Logagent 有本地緩衝，因此不像 Logstash ，在數據傳輸目的地不可用時會丟失日誌。

劣勢

儘管 Logagent 有些比較有意思的功能(例如，接收 Heroku 或 CloudFoundry 日誌)，可是它並無 Logstash 靈活。

典型應用場景

Logagent 做爲一個能夠作全部事情的傳輸工具是值得選擇的(提取、解析、緩衝和傳輸)。

logtail

阿里雲日誌服務的生產者，目前在阿里集團內部機器上運行，通過3年多時間的考驗，目前爲阿里公有云用戶提供日誌收集服務。

採用C++語言實現，對穩定性、資源控制、管理等下過很大的功夫，性能良好。相比於logstash、fluentd的社區支持，logtail功能較爲單一，專一日誌收集功能。

優點

logtail佔用機器cpu、內存資源最少，結合阿里雲日誌服務的E2E體驗良好。

劣勢

logtail目前對特定日誌類型解析的支持較弱，後續須要把這一塊補起來。

rsyslog

絕大多數 Linux 發佈版本默認的 syslog 守護進程，rsyslog 能夠作的不只僅是將日誌從 syslog socket 讀取並寫入 /var/log/messages 。它能夠提取文件、解析、緩衝(磁盤和內存)以及將它們傳輸到多個目的地，包括 Elasticsearch 。能夠今後處找到如何處理 Apache 以及系統日誌。

優點

rsyslog 是經測試過的最快的傳輸工具。若是隻是將它做爲一個簡單的 router/shipper 使用，幾乎全部的機器都會受帶寬的限制，可是它很是擅長處理解析多個規則。它基於語法的模塊(mmnormalize)不管規則數目如何增長，它的處理速度始終是線性增加的。這也就意味着，若是當規則在 20-30 條時，如解析 Cisco 日誌時，它的性能能夠大大超過基於正則式解析的 grok ，達到 100 倍(固然，這也取決於 grok 的實現以及 liblognorm 的版本)。

它同時也是咱們能找到的最輕的解析器，固然這也取決於咱們配置的緩衝。

劣勢

rsyslog 的配置工做須要更大的代價(這裏有一些例子)，這讓兩件事情很是困難：

文檔難以搜索和閱讀，特別是那些對術語比較陌生的開發者。

5.x 以上的版本格式不太同樣(它擴展了 syslogd 的配置格式，同時也仍然支持舊的格式)，儘管新的格式能夠兼容舊格式，可是新的特性(例如，Elasticsearch 的輸出)只在新的配置下才有效，而後舊的插件(例如，Postgres 輸出)只在舊格式下支持。

儘管在配置穩定的狀況下，rsyslog 是可靠的(它自身也提供多種配置方式，最終均可以得到相同的結果)，它仍是存在一些 bug 。

典型應用場景

rsyslog 適合那些很是輕的應用(應用，小VM，Docker容器)。若是須要在另外一個傳輸工具(例如，Logstash)中進行處理，能夠直接經過 TCP 轉發 JSON ，或者鏈接 Kafka/Redis 緩衝。

rsyslog 還適合咱們對性能有着很是嚴格的要求時，特別是在有多個解析規則時。那麼這就值得爲之投入更多的時間研究它的配置。

以爲不錯請點贊支持，歡迎留言或進個人我的羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。