Fluentd
? ? ? Fluentd 創(chuàng)建的初衷主要是盡可能的使用 JSON 作為日志輸出泉褐,所以傳輸工具及其下游的傳輸線不需要猜測(cè)子字符串里面各個(gè)字段的類型。這樣鸟蜡,它為幾乎所有的語言都提供庫(kù)膜赃,這也意味著,我們可以將它插入到我們自定義的程序中揉忘。
優(yōu)勢(shì):
? ? ? ?和多數(shù) Logstash 插件一樣跳座,F(xiàn)luentd 插件是用 Ruby 語言開發(fā)的非常易于編寫維護(hù)。所以它數(shù)量很多癌淮,幾乎所有的源和目標(biāo)存儲(chǔ)都有插件(各個(gè)插件的成熟度也不太一樣)躺坟。這也意味這我們可以用Fluentd 來串聯(lián)所有的東西。
劣勢(shì):
? ? ? ? ?因?yàn)樵诙鄶?shù)應(yīng)用場(chǎng)景下乳蓄,我們會(huì)通過 Fluentd 得到結(jié)構(gòu)化的數(shù)據(jù),它的靈活性并不好夕膀。但是我們?nèi)匀豢梢酝ㄟ^正則表達(dá)式虚倒,來解析非結(jié)構(gòu)化的數(shù)據(jù)。盡管产舞,性能在大多數(shù)場(chǎng)景下都很好魂奥,但它并不是最好的,和 syslog-ng 一樣易猫,它的緩沖只存在與輸出端耻煤,單線程核心以及 Ruby GIL 實(shí)現(xiàn)的插件意味著它大的節(jié)點(diǎn)下性能是受限的,不過准颓,它的資源消耗在大多數(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)樗泻芏嗖寮6曳涂保绻蠖鄶?shù)數(shù)據(jù)源都是自定義的應(yīng)用,所以可以發(fā)現(xiàn)用 fluentd 的庫(kù)要比將日志庫(kù)與其他傳輸工具結(jié)合起來要容易很多峡眶。特別是在我們的應(yīng)用是多種語言編寫的時(shí)候剧防,即我們使用了多種日志庫(kù),日志的行為也不太一樣辫樱。
Filebeat
? ? ?作為 Beats 家族的一員峭拘,F(xiàn)ilebeat 是一個(gè)輕量級(jí)的日志傳輸工具,它的存在正彌補(bǔ)了 Logstash的缺點(diǎn):Filebeat 作為一個(gè)輕量級(jí)的日志傳輸工具可以將日志推送到中心 Logstash。
? ? ? 在版本 5.x 中棚唆,Elasticsearch 具有解析的能力(像 Logstash 過濾器)— 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ì)碰到問題佳恬。例如,如果使用 Logstash作為下游管道于游,我們同樣會(huì)遇到性能問題毁葱。正因?yàn)槿绱耍現(xiàn)ilebeat 的范圍在擴(kuò)大曙砂。開始時(shí)头谜,它只能將日志發(fā)送到 Logstash 和 Elasticsearch,而現(xiàn)在它可以將日志發(fā)送給 Kafka 和 Redis鸠澈,在 5.x 版本中柱告,它還具備過濾的能力。
Logstash
? ? ? ? Logstash 是一個(gè)開源數(shù)據(jù)收集引擎笑陈,具有實(shí)時(shí)管道功能际度。Logstash 可以動(dòng)態(tài)地將來自不同數(shù)據(jù)源的數(shù)據(jù)統(tǒng)一起來,并將數(shù)據(jù)標(biāo)準(zhǔn)化到你所選擇的目的地涵妥。
優(yōu)勢(shì):
? ? ? ?Logstash 主要的優(yōu)點(diǎn)就是它的靈活性乖菱,主要因?yàn)樗泻芏嗖寮敿?xì)的文檔以及直白的配置格式讓它可以在多種場(chǎng)景下應(yīng)用击吱。我們基本上可以在網(wǎng)上找到很多資源岖妄,幾乎可以處理任何問題。
劣勢(shì):
? ? ? Logstash 致命的問題是它的性能以及資源消耗(默認(rèn)的堆大小是 1GB)珍逸。盡管它的性能在近幾年已經(jīng)有很大提升吵取,與它的替代者們相比還是要慢很多的禽额。這里有 Logstash 與 rsyslog 性能對(duì)比以及Logstash 與 filebeat 的性能對(duì)比。它在大數(shù)據(jù)量的情況下會(huì)是個(gè)問題皮官。
? ? ? ? 另一個(gè)問題是它目前不支持緩存脯倒,目前的典型替代方案是將 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à)的問題穷劈,需要調(diào)整日志傳輸?shù)姆绞?log shipper)。
? ? ?當(dāng)判斷 Logstash 的性能是否足夠好時(shí)踊沸,重要的是對(duì)吞吐量的需求有著準(zhǔn)確的估計(jì)歇终,這也決定了需要為L(zhǎng)ogstash 投入多少硬件資源。
Logtail
? ?阿里云日志服務(wù)的生產(chǎn)者逼龟,目前在阿里集團(tuán)內(nèi)部機(jī)器上運(yùn)行评凝,經(jīng)過 3 年多時(shí)間的考驗(yàn),目前為阿里公有云用戶提供日志收集服務(wù)腺律。采用 C++語言實(shí)現(xiàn)奕短,對(duì)穩(wěn)定性、資源控制匀钧、管理等下過很大的功夫翎碑,性能良好。相比于logstash之斯、fluentd 的社區(qū)支持日杈,logtail 功能較為單一,專注日志收集功能。
優(yōu)勢(shì):
? ? ? ? logtail 占用機(jī)器 cpu莉擒、內(nèi)存資源最少酿炸,結(jié)合阿里云日志服務(wù)的 E2E 體驗(yàn)良好。
劣勢(shì):
? ? ? ? logtail 目前對(duì)特定日志類型解析的支持較弱涨冀,后續(xù)需要把這一塊補(bǔ)起來填硕。