概述

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

[[263479]]

Logstash

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

優(yōu)勢(shì)

Logstash 主要的有點(diǎn)就是它的靈活性，主要因?yàn)樗泻芏嗖寮?，詳?xì)的文檔以及直白的配置格式讓它可以在多種場(chǎng)景下應(yīng)用。我們基本上可以在網(wǎng)上找到很多資源，幾乎可以處理任何問(wèn)題。

劣勢(shì)

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

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

典型應(yīng)用場(chǎng)景

因?yàn)?Logstash 自身的靈活性以及網(wǎng)絡(luò)上豐富的資料，Logstash 適用于原型驗(yàn)證階段使用，或者解析非常的復(fù)雜的時(shí)候。在不考慮服務(wù)器資源的情況下，如果服務(wù)器的性能足夠好，我們也可以為每臺(tái)服務(wù)器安裝 Logstash 。我們也不需要使用緩沖，因?yàn)槲募陨砭陀芯彌_的行為，而 Logstash 也會(huì)記住上次處理的位置。

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

隨著日志項(xiàng)目的推進(jìn)，可能會(huì)因?yàn)樾阅芑虼鷥r(jià)的問(wèn)題，需要調(diào)整日志傳輸?shù)姆绞?log shipper)。當(dāng)判斷 Logstash 的性能是否足夠好時(shí)，重要的是對(duì)吞吐量的需求有著準(zhǔn)確的估計(jì)，這也決定了需要為 Logstash 投入多少硬件資源。

Filebeat

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

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

優(yōu)勢(shì)

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

劣勢(shì)

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

典型應(yīng)用場(chǎng)景

Filebeat 在解決某些特定的問(wèn)題時(shí)：日志存于文件，我們希望將日志直接傳輸存儲(chǔ)到 Elasticsearch。這僅在我們只是抓去(grep)它們或者日志是存于 JSON 格式(Filebeat 可以解析 JSON)?；蛘呷绻蛩闶褂?Elasticsearch 的 Ingest 功能對(duì)日志進(jìn)行解析和豐富。

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

Fluentd

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

優(yōu)勢(shì)

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

劣勢(shì)

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

典型應(yīng)用場(chǎng)景

Fluentd 在日志的數(shù)據(jù)源和目標(biāo)存儲(chǔ)各種各樣時(shí)非常合適，因?yàn)樗泻芏嗖寮?。而且，如果大多?shù)數(shù)據(jù)源都是自定義的應(yīng)用，所以可以發(fā)現(xiàn)用 fluentd 的庫(kù)要比將日志庫(kù)與其他傳輸工具結(jié)合起來(lái)要容易很多。特別是在我們的應(yīng)用是多種語(yǔ)言編寫的時(shí)候，即我們使用了多種日志庫(kù)，日志的行為也不太一樣。

Logagent

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

優(yōu)勢(shì)

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

劣勢(shì)

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

典型應(yīng)用場(chǎng)景

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

logtail

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

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

優(yōu)勢(shì)

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

劣勢(shì)

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

rsyslog

絕大多數(shù) Linux 發(fā)布版本默認(rèn)的 syslog 守護(hù)進(jìn)程，rsyslog 可以做的不僅僅是將日志從 syslog socket 讀取并寫入 /var/log/messages 。它可以提取文件、解析、緩沖(磁盤和內(nèi)存)以及將它們傳輸?shù)蕉鄠€(gè)目的地，包括 Elasticsearch 。可以從此處找到如何處理 Apache 以及系統(tǒng)日志。

優(yōu)勢(shì)

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

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

劣勢(shì)

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

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

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

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

典型應(yīng)用場(chǎng)景

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

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