3個開源日志聚合工具
日志聚合系統可以幫助我們進行故障排除和其它任務。以下是三個主要工具介紹。
指標聚合與日志聚合有何不同？日志不能包括指標嗎？日志聚合系統不能做與指標聚合系統相同的事情嗎？
這些是我經常聽到的問題。我還看到供應商推銷他們的日志聚合系統作為所有可觀察問題的解決方案。日志聚合是一個有價值的工具，但它通常對時間序列數據的支持不夠好。
時間序列的指標聚合系統中幾個有價值的功能是專門為時間序列數據定制的固定間隔和存儲系統。固定間隔允許用戶不斷地收集實時的數據結果。如果要求日志聚合系統以固定間隔收集指標數據，它也可以。但是，它的存儲系統沒有針對指標聚合系統中典型的查詢類型進行優化。使用日志聚合工具中的存儲系統處理這些查詢將花費更多的資源和時間。
所以，我們知道日志聚合系統可能不適合時間序列數據，但是它有什么好處呢？日志聚合系統是收集事件數據的好地方。這些無規律的活動是非常重要的。最好的例子為 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 提供 一款更強大的產品，它使用開源核心模式，為分析工具和報告提供了額外的選項。它也可以在谷歌云平臺或 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 開發的工具來說是一個常見的問題，這些工具旨在為每個節點運行一個工具，而內存開銷并不是主要問題。
