Logstash

logstash基于JRuby實現，可以跨平臺運行在JVM上

優點

主要的優點就是它的靈活性，這還主要因為它有很多插件。然后它清楚的文檔已經直白的配置格式讓它可以再多種場景下應用。這樣的良性循環讓我們可以在網上找到很多資源，幾乎可以處理任何問題。

劣勢

Logstash 致命的問題是它的性能以及資源消耗（默認的堆大小是 1GB）。盡管它的性能在近幾年已經有很大提升，與它的替代者們相比還是要慢很多的。因為logstash是jvm跑的，資源消耗比較大，所以后來作者又用golang寫了一個功能較少但是資源消耗也小的輕量級的logstash-forwarder。不過作者只是一個人，elastic.co公司以后，因為es公司本身還收購了另一個開源項目packetbeat，而這個項目專門就是用golang的，有整個團隊，所以es公司干脆把logstash-forwarder的開發工作也合并到同一個golang團隊來搞，于是新的項目就叫filebeat了。logstash 和filebeat都具有日志收集功能，filebeat更輕量，占用資源更少，但logstash 具有filter功能，能過濾分析日志。一般結構都是filebeat采集日志，然后發送到消息隊列，redis，kafaka。然后logstash去獲取，利用filter功能過濾分析，然后存儲到elasticsearch中。

Filebeat

使用Go語言編寫

工作原理：

Filebeat可以保持每個文件的狀態，并且頻繁地把文件狀態從注冊表里更新到磁盤。這里所說的文件狀態是用來記錄上一次Harvster讀取文件時讀取到的位置，以保證能把全部的日志數據都讀取出來，然后發送給output。如果在某一時刻，作為output的ElasticSearch或者Logstash變成了不可用，Filebeat將會把最后的文件讀取位置保存下來，直到output重新可用的時候，快速地恢復文件數據的讀取。在Filebaet運行過程中，每個Prospector的狀態信息都會保存在內存里。如果Filebeat出行了重啟，完成重啟之后，會從注冊表文件里恢復重啟之前的狀態信息，讓FIlebeat繼續從之前已知的位置開始進行數據讀取。

Prospector會為每一個找到的文件保持狀態信息。因為文件可以進行重命名或者是更改路徑，所以文件名和路徑不足以用來識別文件。對于Filebeat來說，都是通過實現存儲的唯一標識符來判斷文件是否之前已經被采集過。

如果在你的使用場景中，每天會產生大量的新文件，你將會發現Filebeat的注冊表文件會變得非常大

優勢

Filebeat 只是一個二進制文件沒有任何依賴。它占用資源極少，盡管它還十分年輕，正式因為它簡單，所以幾乎沒有什么可以出錯的地方，所以它的可靠性還是很高的。它也為我們提供了很多可以調節的點，例如：它以何種方式搜索新的文件，以及當文件有一段時間沒有發生變化時，何時選擇關閉文件句柄。開始時，它只能將日志發送到 Logstash 和 Elasticsearch，而現在它可以將日志發送給 Kafka 和 Redis，在 5.x 版本中，它還具備過濾的能力。這也就意味著可以將數據直接用 Filebeat 推送到 Elasticsearch，并讓 Elasticsearch 既做解析的事情，又做存儲的事情。也不需要使用緩沖，因為 Filebeat 也會和 Logstash 一樣記住上次讀取的偏移。

filebeat只需要10來M內存資源；

典型應用場景

Filebeat 在解決某些特定的問題時：日志存于文件，我們希望

將日志直接傳輸存儲到 Elasticsearch。這僅在我們只是抓去（grep）它們或者日志是存于 JSON 格式（Filebeat 可以解析 JSON）。或者如果打算使用 Elasticsearch 的 Ingest 功能對日志進行解析和豐富。

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

Flume

Flume 是Apache旗下使用JRuby來構建，所以依賴JAVA運行環境。Flume本身最初設計的目的是為了把數據傳入HDFS中（并不是為了采集日志而設計，這和Logstash有根本的區別.
Flume設計成一個分布式的管道架構，可以看作在數據源和目的地之間有一個Agent的網絡，支持數據路由。

每一個agent都由Source，Channel和Sink組成。

Source：Source負責接收輸入數據，并將數據寫入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持監視一個目錄或者文件，解析其中新生成的事件。

Channel：Channel 存儲，緩存從source到Sink的中間數據。可使用不同的配置來做Channel，例如內存，文件，JDBC等。使用內存性能高但不持久，有可能丟數據。使用文件更可靠，但性能不如內存。

Sink：Sink負責從管道中讀出數據并發給下一個Agent或者最終的目的地。Sink支持的不同目的地種類包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

優勢

Flume已經可以支持一個Agent中有多個不同類型的channel和sink，我們可以選擇把Source的數據復制，分發給不同的目的端口，比如：

Flume還自帶了分區和攔截器功能，因此不是像很多實驗者認為的沒有過濾功能

缺點

Luentd和其插件都是由Ruby開發

Logagent

優勢

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

劣勢

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

典型應用場景

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

Fluentd

fluentd基于CRuby實現，并對性能表現關鍵的一些組件用C語言重新實現，整體性能不錯。

fluentd設計簡潔，pipeline內數據傳遞可靠性高。相較于logstash，其插件支持相對少一些。

開源社區中流行的日志收集工具，所以支持相對較好

rsyslog

優勢

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

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

劣勢

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

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

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

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

syslog-ng

可以將 syslog-ng 當作 rsyslog 的替代品（盡管歷史上它們是兩種不同的方式）。它也是一個模塊化的 syslog 守護進程，但是它可以做的事情要比 syslog 多。它可以接收磁盤緩沖并將 Elasticsearch HTTP 作為輸出。它使用 PatternDB 作為語法解析的基礎，作為 Elasticsearch 的傳輸工具，它是一個不錯的選擇。

優勢

和 rsyslog 一樣，作為一個輕量級的傳輸工具，它的性能也非常好。它曾經比 rsyslog 慢很多，但是 2 年前能達到 570K Logs/s 的性能 并不差。并不像 rsyslog ，它有著明確一致的配置格式以及完好的文檔。

劣勢

linux 發布版本轉向使用 rsyslog 的原因是 syslog-ng 高級版曾經有很多功能在開源版中都存在，但是后來又有所限制。我們這里只關注與開源版本，所有的日志傳輸工具都是開源的。現在又有所變化，例如磁盤緩沖，曾經是高級版存在的特性，現在開源版也有。但有些特性，例如帶有應用層的通知的可靠傳輸協議（reliable delivery protocol）還沒有在開源版本中。