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）還沒有在開源版本中。
logtail
阿里雲日誌服務的生產者，目前在阿里集團內部機器上執行，經過3年多時間的考驗，目前為阿里公有云使用者提供日誌收集服務。
採用C++語言實現，對穩定性、資源控制、管理等下過很大的功夫，效能良好。相比於logstash、fluentd的社群支援，logtail功能較為單一，專注日誌收集功能。
| Flume | LogStash | Fluentd | Kafka | Filebeta | Apache Chukwa | |
|---|---|---|---|---|---|---|
| 版本 | 1.8.0 | 6.3 | 6.3 | |||
| 開發語言 | Java1.8 | JRuby | CRuby | Java | go | |
| 簡介 | JSON作為資料格式。，易於解析 | 一個成熟的高效能訊息佇列 | 輕量級的日誌傳輸工具，支援對接logstash，elsearch。 效能非常好，部署簡單 | 活躍度很低 | ||
| 成本 | 開源 | 免費 | 開源 | 開源 | 開源 | 開源 |
| 架構 | Agent由source，channel、sink組成。多個Agent可以組成呼叫鏈 | input、Filter、output組成。 | Input：完成輸入資料的讀取，由source部分配置 Parser：解析外掛 Output：完成輸出資料的操作，由match部分配置 Formatter：訊息格式化的外掛，屬於filter型別 Buffer：快取外掛，用於快取資料 | Filebeta | ||
| 容錯性 | 優秀，訊息傳送事務和重試、下游崩潰時訊息磁碟存檔 | 假如 Logstash 節點發生故障，Logstash 會通過持久化佇列來保證執行中的事件至少一次被送達（at-least-once delivery）。那些未被正常處理的訊息會被送往死信佇列（dead letter queue）以便做進一步處理。由於具備了這種吸收吞吐量的能力，現在您無需採用額外的佇列層，Logstash 就能平穩度過高峰期 | 緩衝，負載平衡，超時和重試的支援。 | 優秀 | 無 | |
| 負載均衡 | 支援sink端故障轉移和負載均衡策略，部落格。 | 支援 | 支援 | 支援 | 支援 | |
| 效能擴充 | 單個Agent配置多個sink提高效能 | 比較注重效能的地方採用C編寫 | 高效能，高吞吐量 | |||
| 功能擴充 | 1. 可以下載原始碼擴充 2.支援開發外掛 | ruby擴充開發外掛 | 需要自己開發各種採集端 | |||
| 採集外掛 | Exec、JMS、Directory、 Tail、Syslog、Http、自定義 | file、syslog、http、kafka、snmp、rabbitmq | 多種，支援SNMP | 無 | 適用於檔案日誌的採集端，替代 logstash-input-file 。 | |
| 快取佇列（快取通道） | Memory、Jdbc、Kafka、File、自定義 | 無，只傳送至Redis或Kafka | 支援快取通道 | 本身有一個很好的儲存機制，支援記憶體和磁碟可靠性 | ||
| 日誌過濾 | 需要自定義採集外掛實現日誌過濾 | 多種Filter外掛：grok、json、drop、mutate、date、clone等，支援結構化解析文字、事件克隆、丟棄、欄位轉換 | 支援多種過濾外掛和解析外掛 | 無 | ||
| 傳送外掛 | HDFS、Hive、File、Null、Hbase、Kafka、Http、自定義 | 多種 | 多種 | 無 | ||
| 效能 | Flume1.4報告 | logstash及filebeat記憶體佔用對比 ，Logstash效能優化 | 測試 | |||
| 缺點 | 沒有snmp外掛 | 效能和資源消耗較大。推薦logbeat採集資料，Logstash過濾日誌。日誌的容錯性沒有flume和fluentd號 | 輸入輸出外掛沒有logstash靈活。中文文件較少 | 沒有可用的採集外掛，更多的是用作訊息快取和轉發 |