Logstash
Logstash 不是這個列表里最老的傳輸工具（最老的應(yīng)該是 syslog-ng ，諷刺的是它也是唯一一個名字里帶有 new 的），但 Logstash 絕對可以稱得上最有名的。因為它有很多插件：輸入、編解碼器、過濾器以及輸出。基本上，可以獲取并豐富任何數(shù)據(jù)，然后將它們推送到多種目標(biāo)存儲。
優(yōu)勢
Logstash 主要的有點(diǎn)就是它的靈活性，這還主要因為它有很多插件。然后它清楚的文檔已經(jīng)直白的配置格式讓它可以再多種場景下應(yīng)用。這樣的良性循環(huán)讓我們可以在網(wǎng)上找到很多資源，幾乎可以處理任何問題。
劣勢
Logstash 致命的問題是它的性能以及資源消耗（默認(rèn)的堆大小是 1GB）。盡管它的性能在近幾年已經(jīng)有很大提升，與它的替代者們相比還是要慢很多的。這里有 Logstash 與 rsyslog 性能對比以及Logstash 與 filebeat 的性能對比。它在大數(shù)據(jù)量的情況下會是個問題。
另一個問題是它目前不支持緩存，目前的典型替代方案是將 Redis 或 Kafka 作為中心緩沖池：
典型應(yīng)用場景
因為 Logstash 自身的靈活性以及網(wǎng)絡(luò)上豐富的資料，Logstash 適用于原型驗證階段使用，或者解析非常的復(fù)雜的時候。在不考慮服務(wù)器資源的情況下，如果服務(wù)器的性能足夠好，我們也可以為每臺服務(wù)器安裝 Logstash 。我們也不需要使用緩沖，因為文件自身就有緩沖的行為，而 Logstash 也會記住上次處理的位置。
如果服務(wù)器性能較差，并不推薦為每個服務(wù)器安裝 Logstash ，這樣就需要一個輕量的日志傳輸工具，將數(shù)據(jù)從服務(wù)器端經(jīng)由一個或多個 Logstash 中心服務(wù)器傳輸?shù)?Elasticsearch：
隨著日志項目的推進(jìn)，可能會因為性能或代價的問題，需要調(diào)整日志傳輸?shù)姆绞剑╨og shipper）。當(dāng)判斷 Logstash 的性能是否足夠好時，重要的是對吞吐量的需求有著準(zhǔn)確的估計，這也決定了需要為 Logstash 投入多少硬件資源。
Filebeat
作為 Beats 家族的一員，F(xiàn)ilebeat 是一個輕量級的日志傳輸工具，它的存在正彌補(bǔ)了 Logstash 的缺點(diǎn)：Filebeat 作為一個輕量級的日志傳輸工具可以將日志推送到中心 Logstash。
在版本 5.x 中，Elasticsearch 具有解析的能力（像 Logstash 過濾器）— Ingest。這也就意味著可以將數(shù)據(jù)直接用 Filebeat 推送到 Elasticsearch，并讓 Elasticsearch 既做解析的事情，又做存儲的事情。也不需要使用緩沖，因為 Filebeat 也會和 Logstash 一樣記住上次讀取的偏移：
如果需要緩沖（例如，不希望將日志服務(wù)器的文件系統(tǒng)填滿），可以使用 Redis/Kafka，因為 Filebeat 可以與它們進(jìn)行通信：
優(yōu)勢
Filebeat 只是一個二進(jìn)制文件沒有任何依賴。它占用資源極少，盡管它還十分年輕，正式因為它簡單，所以幾乎沒有什么可以出錯的地方，所以它的可靠性還是很高的。它也為我們提供了很多可以調(diào)節(jié)的點(diǎn)，例如：它以何種方式搜索新的文件，以及當(dāng)文件有一段時間沒有發(fā)生變化時，何時選擇關(guān)閉文件句柄。
劣勢
Filebeat 的應(yīng)用范圍十分有限，所以在某些場景下我們會碰到問題。例如，如果使用 Logstash 作為下游管道，我們同樣會遇到性能問題。正因為如此，F(xiàn)ilebeat 的范圍在擴(kuò)大。開始時，它只能將日志發(fā)送到 Logstash 和 Elasticsearch，而現(xiàn)在它可以將日志發(fā)送給 Kafka 和 Redis，在 5.x 版本中，它還具備過濾的能力。
典型應(yīng)用場景
Filebeat 在解決某些特定的問題時：日志存于文件，我們希望將日志直接傳輸存儲到 Elasticsearch。這僅在我們只是抓去（grep）它們或者日志是存于 JSON 格式（Filebeat 可以解析 JSON）。或者如果打算使用 Elasticsearch 的 Ingest 功能對日志進(jìn)行解析和豐富。
將日志發(fā)送到 Kafka/Redis。所以另外一個傳輸工具（例如，Logstash 或自定義的 Kafka 消費(fèi)者）可以進(jìn)一步豐富和轉(zhuǎn)發(fā)。這里假設(shè)選擇的下游傳輸工具能夠滿足我們對功能和性能的要求。
Fluentd
Fluentd 創(chuàng)建的初衷主要是盡可能的使用 JSON 作為日志輸出，所以傳輸工具及其下游的傳輸線不需要猜測子字符串里面各個字段的類型。這樣，它為幾乎所有的語言都提供庫，這也意味著，我們可以將它插入到我們自定義的程序中。
優(yōu)勢
和多數(shù) Logstash 插件一樣，F(xiàn)luentd 插件是用 Ruby 語言開發(fā)的非常易于編寫維護(hù)。所以它數(shù)量很多，幾乎所有的源和目標(biāo)存儲都有插件（各個插件的成熟度也不太一樣）。這也意味這我們可以用 Fluentd 來串聯(lián)所有的東西。
劣勢
因為在多數(shù)應(yīng)用場景下，我們會通過 Fluentd 得到結(jié)構(gòu)化的數(shù)據(jù)，它的靈活性并不好。但是我們?nèi)匀豢梢酝ㄟ^正則表達(dá)式，來解析非結(jié)構(gòu)化的數(shù)據(jù)。盡管，性能在大多數(shù)場景下都很好，但它并不是最好的，和 syslog-ng 一樣，它的緩沖只存在與輸出端，單線程核心以及 Ruby GIL 實現(xiàn)的插件意味著它大的節(jié)點(diǎn)下性能是受限的，不過，它的資源消耗在大多數(shù)場景下是可以接受的。對于小的或者嵌入式的設(shè)備，可能需要看看 Fluent Bit，它和 Fluentd 的關(guān)系與 Filebeat 和 Logstash 之間的關(guān)系類似
典型應(yīng)用場景
Fluentd 在日志的數(shù)據(jù)源和目標(biāo)存儲各種各樣時非常合適，因為它有很多插件。而且，如果大多數(shù)數(shù)據(jù)源都是自定義的應(yīng)用，所以可以發(fā)現(xiàn)用 fluentd 的庫要比將日志庫與其他傳輸工具結(jié)合起來要容易很多。特別是在我們的應(yīng)用是多種語言編寫的時候，即我們使用了多種日志庫，日志的行為也不太一樣。
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 靈活。
典型應(yīng)用場景
Logagent 作為一個可以做所有事情的傳輸工具是值得選擇的（提取、解析、緩沖和傳輸）。
logtail
阿里云日志服務(wù)的生產(chǎn)者，目前在阿里集團(tuán)內(nèi)部機(jī)器上運(yùn)行，經(jīng)過3年多時間的考驗，目前為阿里公有云用戶提供日志收集服務(wù)。
采用C++語言實現(xiàn)，對穩(wěn)定性、資源控制、管理等下過很大的功夫，性能良好。相比于logstash、fluentd的社區(qū)支持，logtail功能較為單一，專注日志收集功能。
優(yōu)勢
logtail占用機(jī)器cpu、內(nèi)存資源最少，結(jié)合阿里云日志服務(wù)的E2E體驗良好。
劣勢
logtail目前對特定日志類型解析的支持較弱，后續(xù)需要把這一塊補(bǔ)起來。
rsyslog
絕大多數(shù) Linux 發(fā)布版本默認(rèn)的 syslog 守護(hù)進(jìn)程，rsyslog 可以做的不僅僅是將日志從 syslog socket 讀取并寫入 /var/log/messages 。它可以提取文件、解析、緩沖（磁盤和內(nèi)存）以及將它們傳輸?shù)蕉鄠€目的地，包括 Elasticsearch 。可以從此處找到如何處理 Apache 以及系統(tǒng)日志。
優(yōu)勢
rsyslog 是經(jīng)測試過的最快的傳輸工具。如果只是將它作為一個簡單的 router/shipper 使用，幾乎所有的機(jī)器都會受帶寬的限制，但是它非常擅長處理解析多個規(guī)則。它基于語法的模塊（mmnormalize）無論規(guī)則數(shù)目如何增加，它的處理速度始終是線性增長的。這也就意味著，如果當(dāng)規(guī)則在 20-30 條時，如解析 Cisco 日志時，它的性能可以大大超過基于正則式解析的 grok ，達(dá)到 100 倍（當(dāng)然，這也取決于 grok 的實現(xiàn)以及 liblognorm 的版本）。
它同時也是我們能找到的最輕的解析器，當(dāng)然這也取決于我們配置的緩沖。
劣勢
rsyslog 的配置工作需要更大的代價（這里有一些例子），這讓兩件事情非常困難：
文檔難以搜索和閱讀，特別是那些對術(shù)語比較陌生的開發(fā)者。
5.x 以上的版本格式不太一樣（它擴(kuò)展了 syslogd 的配置格式，同時也仍然支持舊的格式），盡管新的格式可以兼容舊格式，但是新的特性（例如，Elasticsearch 的輸出）只在新的配置下才有效，然后舊的插件（例如，Postgres 輸出）只在舊格式下支持。
盡管在配置穩(wěn)定的情況下，rsyslog 是可靠的（它自身也提供多種配置方式，最終都可以獲得相同的結(jié)果），它還是存在一些 bug 。
典型應(yīng)用場景
rsyslog 適合那些非常輕的應(yīng)用（應(yīng)用，小VM，Docker容器）。如果需要在另一個傳輸工具（例如，Logstash）中進(jìn)行處理，可以直接通過 TCP 轉(zhuǎn)發(fā) JSON ，或者連接 Kafka/Redis 緩沖。
rsyslog 還適合我們對性能有著非常嚴(yán)格的要求時，特別是在有多個解析規(guī)則時。那么這就值得為之投入更多的時間研究它的配置。
syslog-ng
可以將 syslog-ng 當(dāng)作 rsyslog 的替代品（盡管歷史上它們是兩種不同的方式）。它也是一個模塊化的 syslog 守護(hù)進(jìn)程，但是它可以做的事情要比 syslog 多。它可以接收磁盤緩沖并將 Elasticsearch HTTP 作為輸出。它使用 PatternDB 作為語法解析的基礎(chǔ)，作為 Elasticsearch 的傳輸工具，它是一個不錯的選擇。
優(yōu)勢
和 rsyslog 一樣，作為一個輕量級的傳輸工具，它的性能也非常好。它曾經(jīng)比 rsyslog 慢很多，但是 2 年前能達(dá)到 570K Logs/s 的性能并不差。并不像 rsyslog ，它有著明確一致的配置格式以及完好的文檔。
劣勢
Linux 發(fā)布版本轉(zhuǎn)向使用 rsyslog 的原因是 syslog-ng 高級版曾經(jīng)有很多功能在開源版中都存在，但是后來又有所限制。我們這里只關(guān)注與開源版本，所有的日志傳輸工具都是開源的。現(xiàn)在又有所變化，例如磁盤緩沖，曾經(jīng)是高級版存在的特性，現(xiàn)在開源版也有。但有些特性，例如帶有應(yīng)用層的通知的可靠傳輸協(xié)議（reliable delivery protocol）還沒有在開源版本中。
典型應(yīng)用場景
和 rsyslog 類似，可能將 syslog-ng 部署在資源受限的環(huán)境中，但仍希望它能在處理復(fù)雜計算時有著良好的性能。如果使用 rsyslog ，它可以輸出至 Kafka ，以 Kafka 作為一個中心隊列，并以 Logstash 作為一個自定義消費(fèi)者：
不同的是，syslog-ng 使用起來比 rsyslog 更容易，性能沒有 rsyslog 那么極致：例如，它只對輸出進(jìn)行緩沖，所以它所有的計算處理在緩沖之前就完成了，這也意味著它會給日志流帶來壓力。
相關(guān)推薦
