3 個開源日誌聚合工具

指標聚合 metrics aggregation 與 日誌聚合 log aggregation 有何不同？日誌不能包括指標嗎？日誌聚合系統不能做與指標聚合系統相同的事情嗎？

這些是我經常聽到的問題。我還看到供應商推銷他們的日誌聚合系統作為所有可觀察問題的解決方案。日誌聚合是一個有價值的工具，但它通常對時間序列數據的支持不夠好。

時間序列的指標聚合系統中幾個有價值的功能是專門為時間序列數據定製的 固定間隔 regular interval 和存儲系統。固定間隔允許用戶不斷地收集實時的數據結果。如果要求日誌聚合系統以固定間隔收集指標數據，它也可以。但是，它的存儲系統沒有針對指標聚合系統中典型的查詢類型進行優化。使用日誌聚合工具中的存儲系統處理這些查詢將花費更多的資源和時間。

所以，我們知道日誌聚合系統可能不適合時間序列數據，但是它有什麼好處呢？日誌聚合系統是收集事件數據的好地方。這些無規律的活動是非常重要的。最好的例子為 web 服務的訪問日誌，這些很重要，因為我們想知道什麼正在訪問我們的系統，什麼時候訪問的。另一個例子是應用程序錯誤記錄 —— 因為它不是正常的操作記錄，所以在故障排除過程中可能很有價值的。

日誌記錄的一些規則：

• 須包含時間戳
• 須格式化為 JSON
• 不記錄無關緊要的事件
• 須記錄所有應用程序的錯誤
• 可記錄警告錯誤
• 可開關的日誌記錄
• 須以可讀的形式記錄信息
• 不在生產環境中記錄信息
• 不記錄任何無法閱讀或反饋的內容

雲的成本

當研究日誌聚合工具時，雲服務可能看起來是一個有吸引力的選擇。然而，這可能會帶來巨大的成本。當跨數百或數千台主機和應用程序聚合時，日誌數據是大量的。在基於雲的系統中，數據的接收、存儲和檢索是昂貴的。

以一個真實的系統來參考，大約 500 個節點和幾百個應用程序的集合每天產生 200GB 的日誌數據。這個系統可能還有改進的空間，但是在許多 SaaS 產品中，即使將它減少一半，每月也要花費將近 10000 美元。而這通常僅保留 30 天，如果你想查看一年一年的趨勢數據，就不可能了。

並不是要不使用這些基於雲的系統，尤其是對於較小的組織它們可能非常有價值的。這裡的目的是指出可能會有很大的成本，當這些成本很高時，就可能令人非常的沮喪。本文的其餘部分將集中討論自託管的開源和商業解決方案。

工具選擇

ELK

ELK，即 Elasticsearch、Logstash 和 Kibana 簡稱，是最流行的開源日誌聚合工具。它被 Netflix、Facebook、微軟、LinkedIn 和思科使用。這三個組件都是由 Elastic 開發和維護的。Elasticsearch 本質上是一個 NoSQL 資料庫，以 Lucene 搜索引擎實現的。Logstash 是一個日誌管道系統，可以接收數據，轉換數據，並將其載入到像 Elasticsearch 這樣的應用中。Kibana 是 Elasticsearch 之上的可視化層。

幾年前，引入了 Beats 。Beats 是數據採集器。它們簡化了將數據運送到 Logstash 的過程。用戶不需要了解每種日誌的正確語法，而是可以安裝一個 Beats 來正確導出 NGINX 日誌或 Envoy 代理日誌，以便在 Elasticsearch 中有效地使用它們。

安裝生產環境級 ELK 套件時，可能會包括其他幾個部分，如 Kafka、Redis 和 NGINX。此外，用 Fluentd 替換 Logstash 也很常見，我們將在後面討論。這個系統操作起來很複雜，這在早期導致了很多問題和抱怨。目前，這些問題基本上已經被修復，不過它仍然是一個複雜的系統，如果你使用少部分的功能，建議不要使用它了。

也就是說，有其它可用的服務，所以你不必苦惱於此。可以使用 Logz.io，但是如果你有很多數據，它的標價有點高。當然，你可能規模比較小，沒有很多數據。如果你買不起 Logz.io，你可以看看 AWS Elasticsearch Service (ES) 。ES 是 Amazon Web Services (AWS) 提供的一項服務，它很容易就可以讓 Elasticsearch 馬上工作起來。它還擁有使用 Lambda 和 S3 將所有AWS 日誌記錄到 ES 的工具。這是一個更便宜的選擇，但是需要一些管理操作，並有一些功能限制。

ELK 套件的母公司 Elastic 提供 一款更強大的產品，它使用 開源核心 open core 模式，為分析工具和報告提供了額外的選項。它也可以在谷歌雲平台或 AWS 上託管。由於這種工具和託管平台的組合提供了比大多數 SaaS 選項更加便宜，這也許是最好的選擇，並且很有用。該系統可以有效地取代或提供 安全信息和事件管理（SIEM）系統的功能。

ELK 套件通過 Kibana 提供了很好的可視化工具，但是它缺少警報功能。Elastic 在付費的 X-Pack 插件中提供了警報功能，但是在開源系統沒有內置任何功能。Yelp 已經開發了一種解決這個問題的方法，ElastAlert，不過還有其他方式。這個額外的軟體相當健壯，但是它增加了已經複雜的系統的複雜性。

Graylog

Graylog 最近越來越受歡迎，但它是在 2010 年由 Lennart Koopmann 創建並開發的。兩年後，一家公司以同樣的名字誕生了。儘管它的使用者越來越多，但仍然遠遠落後於 ELK 套件。這也意味著它具有較少的社區開發特徵，但是它可以使用與 ELK 套件相同的 Beats 。由於 Graylog Collector Sidecar 使用 Go 編寫，所以 Graylog 在 Go 社區贏得了讚譽。

Graylog 使用 Elasticsearch、MongoDB 和底層的 Graylog Server 。這使得它像 ELK 套件一樣複雜，也許還要複雜一些。然而，Graylog 附帶了內置於開源版本中的報警功能，以及其他一些值得注意的功能，如流、消息重寫和地理定位。

流功能可以允許數據在被處理時被實時路由到特定的 Stream。使用此功能，用戶可以在單個 Stream 中看到所有資料庫錯誤，在另外的 Stream 中看到 web 伺服器錯誤。當添加新項目或超過閾值時，甚至可以基於這些 Stream 提供警報。延遲可能是日誌聚合系統中最大的問題之一，Stream 消除了 Graylog 中的這一問題。一旦日誌進入，它就可以通過 Stream 路由到其他系統，而無需完全處理好。

消息重寫功能使用開源規則引擎 Drools 。允許根據用戶定義的規則文件評估所有傳入的消息，從而可以刪除消息（稱為黑名單）、添加或刪除欄位或修改消息。

Graylog 最酷的功能或許是它的地理定位功能，它支持在地圖上繪製 IP 地址。這是一個相當常見的功能，在 Kibana 也可以這樣使用，但是它增加了很多價值 —— 特別是如果你想將它用作 SIEM 系統。地理定位功能在系統的開源版本中提供。

如果你需要的話，Graylog 公司會提供對開源版本的收費支持。它還為其企業版提供了一個開源核心模式，提供存檔、審計日誌記錄和其他支持。其它提供支持或託管服務的不太多，如果你不需要 Graylog 公司的，你可以託管。

Fluentd

Fluentd 是 Treasure Data 開發的，CNCF 已經將它作為一個孵化項目。它是用 C 和 Ruby 編寫的，並被 AWS 和 Google Cloud 所推薦。Fluentd 已經成為許多系統中 logstach 的常用替代品。它可以作為一個本地聚合器，收集所有節點日誌並將其發送到中央存儲系統。它不是日誌聚合系統。

它使用一個強大的插件系統，提供不同數據源和數據輸出的快速和簡單的集成功能。因為有超過 500 個插件可用，所以你的大多數用例都應該包括在內。如果沒有，這聽起來是一個為開源社區做出貢獻的機會。

Fluentd 由於佔用內存少（只有幾十兆位元組）和高吞吐量特性，是 Kubernetes 環境中的常見選擇。在像 Kubernetes 這樣的環境中，每個 pod 都有一個 Fluentd 附屬件 ，內存消耗會隨著每個新 pod 的創建而線性增加。在這種情況下，使用 Fluentd 將大大降低你的系統利用率。這對於 Java 開發的工具來說是一個常見的問題，這些工具旨在為每個節點運行一個工具，而內存開銷並不是主要問題。

via: https://opensource.com/article/18/9/open-source-log-aggregation-tools

作者：Dan Barker 選題：lujun9972 譯者：heguangzhi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive