ELK 性能—Logstash 性能及其替代方案

介紹

當談及集中日誌到 Elasticsearch 時，首先想到的日誌傳輸（log shipper）就是 Logstash。開發者聽說過它，但是不太清楚它具體是幹什麼事情的：

當深入這個話題時，我們才明白集中存儲日誌通常隱含著很多的事情，Logstash 也不是唯一的日誌傳輸工具（log shipper）

• 從數據源獲取數據：文件、UNIX socket、TCP、UDP 等等
• 處理：添加時間戳、解析非結構化數據、根據 IP 添加地理位置信息
• 傳輸：到目標存儲。比如，Elasticsearch 。由於 Elasticsearch 可能會宕機，或正存在性能問題，或網絡存在問題，那麼傳輸工具最好就需要有能力提供緩衝以及重試。

本篇博文旨在比較 Logstash 已經它的五種替代方案（Filebeat、Fluentd、rsyslog、syslog-ng 以及 Logagent），這樣就可以知道它們各適合於何種場景。

分析

Logstash

Logstash 不是這個列表裡最老的傳輸工具（最老的應該是 syslog-ng ，諷刺的是它也是唯一一個名字裡帶有 new 的），但 Logstash 絕對可以稱得上最有名的。因為它有很多插件：輸入、編解碼器、過濾器以及輸出。基本上，可以獲取並豐富任何數據，然後將它們推送到多種目標存儲。

優勢

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 的性能對比。它在大數據量的情況下會是個問題。

另一個問題是它目前不支持緩存，目前的典型替代方案是將 Redis 或 Kafka 作為中心緩衝池：

典型應用場景

因為 Logstash 自身的靈活性以及網絡上豐富的資料，Logstash 適用於原型驗證階段使用，或者解析非常的複雜的時候。在不考慮服務器資源的情況下，如果服務器的性能足夠好，我們也可以為每臺服務器安裝 Logstash 。我們也不需要使用緩衝，因為文件自身就有緩衝的行為，而 Logstash 也會記住上次處理的位置。

如果服務器性能較差，並不推薦為每個服務器安裝 Logstash ，這樣就需要一個輕量的日誌傳輸工具，將數據從服務器端經由一個或多個 Logstash 中心服務器傳輸到 Elasticsearch：

隨著日誌項目的推進，可能會因為性能或代價的問題，需要調整日誌傳輸的方式（log shipper）。當判斷 Logstash 的性能是否足夠好時，重要的是對吞吐量的需求有著準確的估計，這也決定了需要為 Logstash 投入多少硬件資源。

Filebeat

作為 Beats 家族的一員，Filebeat 是一個輕量級的日誌傳輸工具，它的存在正彌補了 Logstash 的缺點：Filebeat 作為一個輕量級的日誌傳輸工具可以將日誌推送到中心 Logstash。

在版本 5.x 中，Elasticsearch 具有解析的能力（像 Logstash 過濾器）— Ingest。這也就意味著可以將數據直接用 Filebeat 推送到 Elasticsearch，並讓 Elasticsearch 既做解析的事情，又做存儲的事情。也不需要使用緩衝，因為 Filebeat 也會和 Logstash 一樣記住上次讀取的偏移：

如果需要緩衝（例如，不希望將日誌服務器的文件系統填滿），可以使用 Redis/Kafka，因為 Filebeat 可以與它們進行通信：

優勢

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

劣勢

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

典型應用場景

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

• 將日誌直接傳輸存儲到 Elasticsearch。這僅在我們只是抓去（grep）它們或者日誌是存於 JSON 格式（Filebeat 可以解析 JSON）。或者如果打算使用 Elasticsearch 的 Ingest 功能對日誌進行解析和豐富。
• 將日誌發送到 Kafka/Redis。所以另外一個傳輸工具（例如，Logstash 或自定義的 Kafka 消費者）可以進一步豐富和轉發。這裡假設選擇的下游傳輸工具能夠滿足我們對功能和性能的要求。

Logagent

Logagent 是 Sematext 提供的傳輸工具，它用來將日誌傳輸到 Logsene（一個基於 SaaS 平臺的 Elasticsearch API），因為 Logsene 會暴露 Elasticsearch API，所以 Logagent 可以很容易將數據推送到 Elasticsearch 。

優勢

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

劣勢

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

典型應用場景

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

rsyslog

絕大多數 Linux 發佈版本默認的 syslog 守護進程，rsyslog 可以做的不僅僅是將日誌從 syslog socket 讀取並寫入 /var/log/messages 。它可以提取文件、解析、緩衝（磁盤和內存）以及將它們傳輸到多個目的地，包括 Elasticsearch 。可以從此處找到如何處理 Apache 以及系統日誌。

優勢

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

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

劣勢

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

• 文檔難以搜索和閱讀，特別是那些對術語比較陌生的開發者。
• 5.x 以上的版本格式不太一樣（它擴展了 syslogd 的配置格式，同時也仍然支持舊的格式），儘管新的格式可以兼容舊格式，但是新的特性（例如，Elasticsearch 的輸出）只在新的配置下才有效，然後舊的插件（例如，Postgres 輸出）只在舊格式下支持。

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

典型應用場景

rsyslog 適合那些非常輕的應用（應用，小VM，Docker容器）。如果需要在另一個傳輸工具（例如，Logstash）中進行處理，可以直接通過 TCP 轉發 JSON ，或者連接 Kafka/Redis 緩衝。

rsyslog 還適合我們對性能有著非常嚴格的要求時，特別是在有多個解析規則時。那麼這就值得為之投入更多的時間研究它的配置。

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）還沒有在開源版本中。

典型應用場景

和 rsyslog 類似，可能將 syslog-ng 部署在資源受限的環境中，但仍希望它能在處理複雜計算時有著良好的性能。如果使用 rsyslog ，它可以輸出至 Kafka ，以 Kafka 作為一箇中心隊列，並以 Logstash 作為一個自定義消費者：

不同的是，syslog-ng 使用起來比 rsyslog 更容易，性能沒有 rsyslog 那麼極致：例如，它只對輸出進行緩衝，所以它所有的計算處理在緩衝之前就完成了，這也意味著它會給日誌流帶來壓力。

Fluentd

Fluentd 創建的初衷主要是儘可能的使用 JSON 作為日誌輸出，所以傳輸工具及其下游的傳輸線不需要猜測子字符串裡面各個字段的類型。這樣，它為幾乎所有的語言都提供庫，這也意味著，我們可以將它插入到我們自定義的程序中。

優勢

和多數 Logstash 插件一樣，Fluentd 插件是用 Ruby 語言開發的非常易於編寫維護。所以它數量很多，幾乎所有的源和目標存儲都有插件（各個插件的成熟度也不太一樣）。這也意味這我們可以用 Fluentd 來串聯所有的東西。

劣勢

因為在多數應用場景下，我們會通過 Fluentd 得到結構化的數據，它的靈活性並不好。但是我們仍然可以通過正則表達式，來解析非結構化的數據。儘管，性能在大多數場景下都很好，但它並不是最好的，和 syslog-ng 一樣，它的緩衝只存在與輸出端，單線程核心以及 Ruby GIL 實現的插件意味著它大的節點下性能是受限的，不過，它的資源消耗在大多數場景下是可以接受的。對於小的或者嵌入式的設備，可能需要看看 Fluent Bit，它和 Fluentd 的關係與 Filebeat 和 Logstash 之間的關係類似

典型應用場景

Fluentd 在日誌的數據源和目標存儲各種各樣時非常合適，因為它有很多插件。而且，如果大多數數據源都是自定義的應用，所以可以發現用 fluentd 的庫要比將日誌庫與其他傳輸工具結合起來要容易很多。特別是在我們的應用是多種語言編寫的時候，即我們使用了多種日誌庫，日誌的行為也不太一樣。

結論

工具的選擇由使用場景決定

參考

Logstash Alternatives

本文轉自:https://www.cnblogs.com/richaaaard/p/6109595.html