當前位置:編程學習大全網 - 源碼下載 - Logstash 五種替代方案(Filebeat、Fluentd、rsyslog、syslog-ng 以及 Logagent

Logstash 五種替代方案(Filebeat、Fluentd、rsyslog、syslog-ng 以及 Logagent

優勢

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

5 minute intro

reindexing data in Elasticsearch

parsing Elasticsearch logs

rewriting Elasticsearch slowlogs so you can replay them with JMeter

劣勢

Logstash 致命的問題是它的性能以及資源消耗(默認的堆大小是 1GB)。盡管它的性能在近幾年已經有很大提升,與它的替代者們相比還是要慢很多的。這裏有 Logstash 與 rsyslog 性能對比 以及 Logstash 與 filebeat 的性能對比 。它在大數據量的情況下會是個問題。

優勢

Filebeat 只是壹個二進制文件沒有任何依賴。它占用資源極少,盡管它還十分年輕,正式因為它簡單,所以幾乎沒有什麽可以出錯的地方,所以它的可靠性還是很高的。它也為我們提供了很多可以調節的點,例如:它以何種方式搜索新的文件,以及當文件有壹段時間沒有發生變化時,何時選擇關閉文件句柄。

劣勢

Filebeat 的應用範圍十分有限,所以在某些場景下我們會碰到問題。例如,如果使用 Logstash 作為下遊管道,我們同樣會遇到性能問題。正因為如此,Filebeat 的範圍在擴大。開始時,它只能將日誌發送到 Logstash 和 Elasticsearch,而現在它可以將日誌發送給 Kafka 和 Redis,在 5.x 版本中,它還具備過濾的能力。

典型應用場景

Filebeat 在解決某些特定的問題時:日誌存於文件,我們希望

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

將日誌發送到 Kafka/Redis 。所以另外壹個傳輸工具(例如,Logstash 或自定義的 Kafka 消費者)可以進壹步豐富和轉發。這裏假設選擇的下遊傳輸工具能夠滿足我們對功能和性能的要求

優勢

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

劣勢

盡管 Logagent 有些比較有意思的功能(例如,接收 Heroku 或 CloudFoundry 日誌),但是它並沒有 Logstash 靈活。

典型應用場景

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

優勢

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

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

劣勢

rsyslog 的配置工作需要更大的代價(這裏有壹些 例子 ),這讓兩件事情非常困難:

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

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

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

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

優勢

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

劣勢

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

  • 上一篇:請問哪位高人幫我解決壹下:dev c++與vc++有沒有區別。
  • 下一篇:vue的組件與框架結構如何選用
  • copyright 2024編程學習大全網