概述

常見的日志采集工具有Logstash、Filebeat、Fluentd、Logagent、rsyslog等等，那么他們之間有什么區別呢?什么情況下我們應該用哪一種工具?

[[263479]]

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 還適合我們對性能有著非常嚴格的要求時，特別是在有多個解析規則時。那么這就值得為之投入更多的時間研究它的配置。