Logstash
優(yōu)勢
Logstash 主要的有點就是它的靈活性程剥，這還主要因為它有很多插件织鲸。然后它清楚的文檔已經(jīng)直白的配置格式讓它可以再多種場景下應用。這樣的良性循環(huán)讓我們可以在網(wǎng)上找到很多資源昙沦，幾乎可以處理任何問題盾饮。以下是一些例子：
5 minute intro
reindexing data in Elasticsearch
parsing Elasticsearch logs
rewriting Elasticsearch slowlogs so you can replay them with JMeter
劣勢
Logstash 致命的問題是它的性能以及資源消耗（默認的堆大小是 1GB）丘损。盡管它的性能在近幾年已經(jīng)有很大提升徘钥，與它的替代者們相比還是要慢很多的。這里有 Logstash 與 rsyslog 性能對比以及Logstash 與 filebeat 的性能對比呈础。它在大數(shù)據(jù)量的情況下會是個問題而钞。
Filebeat
優(yōu)勢
Filebeat 只是一個二進制文件沒有任何依賴臼节。它占用資源極少，盡管它還十分年輕网缝，正式因為它簡單粉臊，所以幾乎沒有什么可以出錯的地方溢吻，所以它的可靠性還是很高的促王。它也為我們提供了很多可以調(diào)節(jié)的點，例如：它以何種方式搜索新的文件阅畴，以及當文件有一段時間沒有發(fā)生變化時迅耘，何時選擇關(guān)閉文件句柄。
劣勢
Filebeat 的應用范圍十分有限纽哥，所以在某些場景下我們會碰到問題。例如晓避，如果使用 Logstash 作為下游管道俏拱，我們同樣會遇到性能問題吼句。正因為如此惕艳，F(xiàn)ilebeat 的范圍在擴大。開始時尔许，它只能將日志發(fā)送到 Logstash 和 Elasticsearch终娃，而現(xiàn)在它可以將日志發(fā)送給 Kafka 和 Redis，在 5.x 版本中余佛，它還具備過濾的能力辉巡。
典型應用場景
Filebeat 在解決某些特定的問題時：日志存于文件蕊退，我們希望
將日志直接傳輸存儲到 Elasticsearch。這僅在我們只是抓去（grep）它們或者日志是存于 JSON 格式（Filebeat 可以解析 JSON）瓤荔∈湎酰或者如果打算使用 Elasticsearch 的 Ingest 功能對日志進行解析和豐富。
將日志發(fā)送到 Kafka/Redis橘荠。所以另外一個傳輸工具（例如哥童，Logstash 或自定義的 Kafka 消費者）可以進一步豐富和轉(zhuǎn)發(fā)贮懈。這里假設選擇的下游傳輸工具能夠滿足我們對功能和性能的要求
Logagent
優(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 靈活不脯。
典型應用場景
Logagent 作為一個可以做所有事情的傳輸工具是值得選擇的（提取、解析富腊、緩沖和傳輸）赘被。
rsyslog
優(yōu)勢
rsyslog 是經(jīng)測試過的最快的傳輸工具民假。如果只是將它作為一個簡單的 router/shipper 使用羊异，幾乎所有的機器都會受帶寬的限制，但是它非常擅長處理解析多個規(guī)則易迹。它基于語法的模塊（mmnormalize）無論規(guī)則數(shù)目如何增加睹欲，它的處理速度始終是線性增長的一屋。這也就意味著窘疮，如果當規(guī)則在 20-30 條時，如解析 Cisco 日志時冀墨，它的性能可以大大超過基于正則式解析的 grok 闸衫，達到 100 倍（當然，這也取決于 grok 的實現(xiàn)以及 liblognorm 的版本）诽嘉。
它同時也是我們能找到的最輕的解析器蔚出，當然這也取決于我們配置的緩沖。
劣勢
rsyslog 的配置工作需要更大的代價（這里有一些例子）含懊，這讓兩件事情非常困難：
文檔難以搜索和閱讀，特別是那些對術(shù)語比較陌生的開發(fā)者衅胀。
5.x 以上的版本格式不太一樣（它擴展了 syslogd 的配置格式岔乔，同時也仍然支持舊的格式），盡管新的格式可以兼容舊格式滚躯，但是新的特性（例如，Elasticsearch 的輸出）只在新的配置下才有效茁影，然后舊的插件（例如愿待，Postgres 輸出）只在舊格式下支持要出。
盡管在配置穩(wěn)定的情況下囱挑，rsyslog 是可靠的（它自身也提供多種配置方式，最終都可以獲得相同的結(jié)果），它還是存在一些 bug 棠隐。
syslog-ng
可以將 syslog-ng 當作 rsyslog 的替代品（盡管歷史上它們是兩種不同的方式）嗡贺。它也是一個模塊化的 syslog 守護進程帕涌，但是它可以做的事情要比 syslog 多。它可以接收磁盤緩沖并將 Elasticsearch HTTP 作為輸出。它使用 PatternDB 作為語法解析的基礎，作為 Elasticsearch 的傳輸工具末秃，它是一個不錯的選擇。
優(yōu)勢
和 rsyslog 一樣，作為一個輕量級的傳輸工具绘盟，它的性能也非常好锡垄。它曾經(jīng)比 rsyslog 慢很多千贯，但是 2 年前能達到 570K Logs/s 的性能并不差己沛。并不像 rsyslog ，它有著明確一致的配置格式以及完好的文檔。
劣勢
Linux 發(fā)布版本轉(zhuǎn)向使用 rsyslog 的原因是 syslog-ng 高級版曾經(jīng)有很多功能在開源版中都存在，但是后來又有所限制空镜。我們這里只關(guān)注與開源版本砂蔽，所有的日志傳輸工具都是開源的。現(xiàn)在又有所變化怀酷，例如磁盤緩沖样眠，曾經(jīng)是高級版存在的特性被丧，現(xiàn)在開源版也有蝇摸。但有些特性啡专，例如帶有應用層的通知的可靠傳輸協(xié)議（reliable delivery protocol）還沒有在開源版本中。
