3 個開源日誌聚合工具 | Linux 中國

日誌聚合系統可以幫助我們進行故障排除和其它任務。以下是三個主要工具介紹。

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

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

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

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

日誌記錄的一些規則：

雲的成本

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

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

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

工具選擇

ELK

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

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

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

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

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

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

Graylog

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

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

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

訊息重寫功能使用開源規則引擎 Drools[17] 。允許根據使用者定義的規則檔案評估所有傳入的訊息，從而可以刪除訊息（稱為黑名單）、新增或刪除欄位或修改訊息。

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

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

Fluentd

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

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

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

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

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

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