概述

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

[[263479]]

Logstash

Logstash是一個開源數(shù)據(jù)收集引擎，具有實時管道功能。Logstash可以動態(tài)地將來自不同數(shù)據(jù)源的數(shù)據(jù)統(tǒng)一起來，并將數(shù)據(jù)標準化到你所選擇的目的地。

優(yōu)勢

Logstash 主要的有點就是它的靈活性，主要因為它有很多插件，詳細的文檔以及直白的配置格式讓它可以在多種場景下應用。我們基本上可以在網(wǎng)上找到很多資源，幾乎可以處理任何問題。

劣勢

Logstash 致命的問題是它的性能以及資源消耗(默認的堆大小是 1GB)。盡管它的性能在近幾年已經(jīng)有很大提升，與它的替代者們相比還是要慢很多的。這里有 Logstash 與 rsyslog 性能對比以及Logstash 與 filebeat 的性能對比。它在大數(shù)據(jù)量的情況下會是個問題。

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

典型應用場景

因為 Logstash 自身的靈活性以及網(wǎng)絡上豐富的資料，Logstash 適用于原型驗證階段使用，或者解析非常的復雜的時候。在不考慮服務器資源的情況下，如果服務器的性能足夠好，我們也可以為每臺服務器安裝 Logstash 。我們也不需要使用緩沖，因為文件自身就有緩沖的行為，而 Logstash 也會記住上次處理的位置。

如果服務器性能較差，并不推薦為每個服務器安裝 Logstash ，這樣就需要一個輕量的日志傳輸工具，將數(shù)據(jù)從服務器端經(jīng)由一個或多個 Logstash 中心服務器傳輸?shù)?Elasticsearch：

隨著日志項目的推進，可能會因為性能或代價的問題，需要調(diào)整日志傳輸?shù)姆绞?log shipper)。當判斷 Logstash 的性能是否足夠好時，重要的是對吞吐量的需求有著準確的估計，這也決定了需要為 Logstash 投入多少硬件資源。

Filebeat

作為 Beats 家族的一員，F(xiàn)ilebeat 是一個輕量級的日志傳輸工具，它的存在正彌補了 Logstash 的缺點：Filebeat 作為一個輕量級的日志傳輸工具可以將日志推送到中心 Logstash。

在版本 5.x 中，Elasticsearch 具有解析的能力(像 Logstash 過濾器)— Ingest。這也就意味著可以將數(shù)據(jù)直接用 Filebeat 推送到 Elasticsearch，并讓 Elasticsearch 既做解析的事情，又做存儲的事情。也不需要使用緩沖，因為 Filebeat 也會和 Logstash 一樣記住上次讀取的偏移，如果需要緩沖(例如，不希望將日志服務器的文件系統(tǒng)填滿)，可以使用 Redis/Kafka，因為 Filebeat 可以與它們進行通信。

優(yōu)勢

Filebeat 只是一個二進制文件沒有任何依賴。它占用資源極少，盡管它還十分年輕，正式因為它簡單，所以幾乎沒有什么可以出錯的地方，所以它的可靠性還是很高的。它也為我們提供了很多可以調(diào)節(jié)的點，例如：它以何種方式搜索新的文件，以及當文件有一段時間沒有發(fā)生變化時，何時選擇關閉文件句柄。

劣勢

Filebeat 的應用范圍十分有限，所以在某些場景下我們會碰到問題。例如，如果使用 Logstash 作為下游管道，我們同樣會遇到性能問題。正因為如此，F(xiàn)ilebeat 的范圍在擴大。開始時，它只能將日志發(fā)送到 Logstash 和 Elasticsearch，而現(xiàn)在它可以將日志發(fā)送給 Kafka 和 Redis，在 5.x 版本中，它還具備過濾的能力。

典型應用場景

Filebeat 在解決某些特定的問題時：日志存于文件，我們希望將日志直接傳輸存儲到 Elasticsearch。這僅在我們只是抓去(grep)它們或者日志是存于 JSON 格式(Filebeat 可以解析 JSON)。或者如果打算使用 Elasticsearch 的 Ingest 功能對日志進行解析和豐富。

將日志發(fā)送到 Kafka/Redis。所以另外一個傳輸工具(例如，Logstash 或自定義的 Kafka 消費者)可以進一步豐富和轉(zhuǎn)發(fā)。這里假設選擇的下游傳輸工具能夠滿足我們對功能和性能的要求。

Fluentd

Fluentd 創(chuàng)建的初衷主要是盡可能的使用 JSON 作為日志輸出，所以傳輸工具及其下游的傳輸線不需要猜測子字符串里面各個字段的類型。這樣，它為幾乎所有的語言都提供庫，這也意味著，我們可以將它插入到我們自定義的程序中。

優(yōu)勢

和多數(shù) Logstash 插件一樣，F(xiàn)luentd 插件是用 Ruby 語言開發(fā)的非常易于編寫維護。所以它數(shù)量很多，幾乎所有的源和目標存儲都有插件(各個插件的成熟度也不太一樣)。這也意味這我們可以用 Fluentd 來串聯(lián)所有的東西。

劣勢

因為在多數(shù)應用場景下，我們會通過 Fluentd 得到結構化的數(shù)據(jù)，它的靈活性并不好。但是我們?nèi)匀豢梢酝ㄟ^正則表達式，來解析非結構化的數(shù)據(jù)。盡管，性能在大多數(shù)場景下都很好，但它并不是***的，和 syslog-ng 一樣，它的緩沖只存在與輸出端，單線程核心以及 Ruby GIL 實現(xiàn)的插件意味著它大的節(jié)點下性能是受限的，不過，它的資源消耗在大多數(shù)場景下是可以接受的。對于小的或者嵌入式的設備，可能需要看看 Fluent Bit，它和 Fluentd 的關系與 Filebeat 和 Logstash 之間的關系類似。

典型應用場景

Fluentd 在日志的數(shù)據(jù)源和目標存儲各種各樣時非常合適，因為它有很多插件。而且，如果大多數(shù)數(shù)據(jù)源都是自定義的應用，所以可以發(fā)現(xiàn)用 fluentd 的庫要比將日志庫與其他傳輸工具結合起來要容易很多。特別是在我們的應用是多種語言編寫的時候，即我們使用了多種日志庫，日志的行為也不太一樣。

Logagent

Logagent 是 Sematext 提供的傳輸工具，它用來將日志傳輸?shù)?Logsene(一個基于 SaaS 平臺的 Elasticsearch API)，因為 Logsene 會暴露 Elasticsearch API，所以 Logagent 可以很容易將數(shù)據(jù)推送到 Elasticsearch 。

優(yōu)勢

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

劣勢

盡管 Logagent 有些比較有意思的功能(例如，接收 Heroku 或 CloudFoundry 日志)，但是它并沒有 Logstash 靈活。

典型應用場景

Logagent 作為一個可以做所有事情的傳輸工具是值得選擇的(提取、解析、緩沖和傳輸)。

logtail

阿里云日志服務的生產(chǎn)者，目前在阿里集團內(nèi)部機器上運行，經(jīng)過3年多時間的考驗，目前為阿里公有云用戶提供日志收集服務。

采用C++語言實現(xiàn)，對穩(wěn)定性、資源控制、管理等下過很大的功夫，性能良好。相比于logstash、fluentd的社區(qū)支持，logtail功能較為單一，專注日志收集功能。

優(yōu)勢

logtail占用機器cpu、內(nèi)存資源最少，結合阿里云日志服務的E2E體驗良好。

劣勢

logtail目前對特定日志類型解析的支持較弱，后續(xù)需要把這一塊補起來。

rsyslog

絕大多數(shù) Linux 發(fā)布版本默認的 syslog 守護進程，rsyslog 可以做的不僅僅是將日志從 syslog socket 讀取并寫入 /var/log/messages 。它可以提取文件、解析、緩沖(磁盤和內(nèi)存)以及將它們傳輸?shù)蕉鄠€目的地，包括 Elasticsearch ?？梢詮拇颂幷业饺绾翁幚?Apache 以及系統(tǒng)日志。

優(yōu)勢

rsyslog 是經(jīng)測試過的最快的傳輸工具。如果只是將它作為一個簡單的 router/shipper 使用，幾乎所有的機器都會受帶寬的限制，但是它非常擅長處理解析多個規(guī)則。它基于語法的模塊(mmnormalize)無論規(guī)則數(shù)目如何增加，它的處理速度始終是線性增長的。這也就意味著，如果當規(guī)則在 20-30 條時，如解析 Cisco 日志時，它的性能可以大大超過基于正則式解析的 grok ，達到 100 倍(當然，這也取決于 grok 的實現(xiàn)以及 liblognorm 的版本)。

它同時也是我們能找到的最輕的解析器，當然這也取決于我們配置的緩沖。

劣勢

rsyslog 的配置工作需要更大的代價(這里有一些例子)，這讓兩件事情非常困難：

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

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

盡管在配置穩(wěn)定的情況下，rsyslog 是可靠的(它自身也提供多種配置方式，最終都可以獲得相同的結果)，它還是存在一些 bug 。

典型應用場景

rsyslog 適合那些非常輕的應用(應用，小VM，Docker容器)。如果需要在另一個傳輸工具(例如，Logstash)中進行處理，可以直接通過 TCP 轉(zhuǎn)發(fā) JSON ，或者連接 Kafka/Redis 緩沖。

rsyslog 還適合我們對性能有著非常嚴格的要求時，特別是在有多個解析規(guī)則時。那么這就值得為之投入更多的時間研究它的配置。