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)樗泻芏嗖寮６曳涂保绻蠖鄶?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ǔ)起來填硕。
