日誌系統新貴 Loki，確實比笨重的 ELK 輕

最近，在對公司容器雲的日誌方案進行設計的時候，發現主流的 ELK 或者 EFK 比較重，再加上現階段對於 ES 複雜的搜索功能很多都用不上最終選擇了 Grafana 開源的 Loki 日誌系統，下面介紹下 Loki 的背景。

背景和動機

當我們的容器雲運行的應用或者某個節點出現問題了，解決思路應該如下：

我們的監控使用的是基於 prometheus 體系進行改造的，prometheus 中比較重要的是 metric 和 alert,metric 是來說明當前或者歷史達到了某個值，alert 設置 metric 達到某個特定的基數觸發了告警，但是這些信息明顯是不夠的。我們都知道，k8s 的基本單位是 pod,pod 把日誌輸出到 stdout 和 stderr, 平時有什麼問題我們通常在界面或者通過命令查看相關的日誌, 舉個例子：當我們的某個 pod 的內存變得很大，觸發了我們的 alert，這個時候管理員，去頁面查詢確認是哪個 pod 有問題，然後要確認 pod 內存變大的原因，我們還需要去查詢 pod 的日誌，如果沒有日誌系統，那麼我們就需要到頁面或者使用命令進行查詢了：如果，這個時候應用突然掛了，這個時候我們就無法查到相關的日誌了，所以需要引入日誌系統，統一收集日誌，而使用 ELK 的話，就需要在 Kibana 和 Grafana 之間切換，影響用戶體驗。所以 ，loki 的第一目的就是最小化度量和日誌的切換成本，有助於減少異常事件的響應時間和提高用戶的體驗

ELK 存在的問題

現有的很多日誌採集的方案都是採用全文檢索對日誌進行索引（如 ELK 方案），優點是功能豐富，允許複雜的操作。但是，這些方案往往規模複雜，資源佔用高，操作苦難。很多功能往往用不上，大多數查詢只關注一定時間範圍和一些簡單的參數（如 host、service 等），使用這些解決方案就有點殺雞用牛刀的感覺了。因此，Loki 的第二個目的是，在查詢語言的易操作性和複雜性之間可以達到一個權衡。

成本

全文檢索的方案也帶來成本問題，簡單的說就是全文搜索（如 ES）的倒排索引的切分和共享的成本較高。後來出現了其他不同的設計方案如：OKlog(https://github.com/oklog/oklog), 採用最終一致的、基於網格的分佈策略。這兩個設計決策提供了大量的成本降低和非常簡單的操作，但是查詢不夠方便。因此，Loki 的第三個目的是，提高一個更具成本效益的解決方案。

整體架構

Loki 的架構如下：不難看出，Loki 的架構非常簡單，使用了和 prometheus 一樣的標籤來作爲索引，也就是說，你通過這些標籤既可以查詢日誌的內容也可以查詢到監控的數據，不但減少了兩種查詢之間的切換成本，也極大地降低了日誌索引的存儲。Loki 將使用與 prometheus 相同的服務發現和標籤重新標記庫, 編寫了 pormtail, 在 k8s 中 promtail 以 daemonset 方式運行在每個節點中，通過 kubernetes api 等到日誌的正確元數據，並將它們發送到 Loki。下面是日誌的存儲架構：

讀寫

日誌數據的寫主要依託的是 Distributor 和 Ingester 兩個組件, 整體的流程如下：

Distributor

一旦 promtail 收集日誌並將其發送給 loki，Distributor 就是第一個接收日誌的組件。由於日誌的寫入量可能很大，所以不能在它們傳入時將它們寫入數據庫。這會毀掉數據庫。我們需要批處理和壓縮數據。

Loki 通過構建壓縮數據塊來實現這一點，方法是在日誌進入時對其進行 gzip 操作，組件 ingester 是一個有狀態的組件，負責構建和刷新 chunck，當 chunk 達到一定的數量或者時間後，刷新到存儲中去。每個流的日誌對應一個 ingester, 當日志到達 Distributor 後，根據元數據和 hash 算法計算出應該到哪個 ingester 上面。此外，爲了冗餘和彈性，我們將其複製 n（默認情況下爲 3）次。

Ingester

ingester 接收到日誌並開始構建 chunk: 基本上就是將日誌進行壓縮並附加到 chunk 上面。一旦 chunk“填滿”（數據達到一定數量或者過了一定期限），ingester 將其刷新到數據庫。我們對塊和索引使用單獨的數據庫，因爲它們存儲的數據類型不同。

刷新一個 chunk 之後，ingester 然後創建一個新的空 chunk 並將新條目添加到該 chunk 中。

Querier

讀取就非常簡單了，由 Querier 負責給定一個時間範圍和標籤選擇器，Querier 查看索引以確定哪些塊匹配，並通過 greps 將結果顯示出來。它還從 Ingester 獲取尚未刷新的最新數據。

對於每個查詢，一個查詢器將爲您顯示所有相關日誌。實現了查詢並行化，提供分佈式 grep，使即使是大型查詢也是足夠的。

可擴展性

Loki 的索引存儲可以是 cassandra/bigtable/dynamodb，而 chuncks 可以是各種對象存儲，Querier 和 Distributor 都是無狀態的組件。對於 ingester 他雖然是有狀態的但是，當新的節點加入或者減少，整節點間的 chunk 會重新分配，已適應新的散列環。而 Loki 底層存儲的實現 Cortex 已經 在實際的生產中投入使用多年了。有了這句話，我可以放心的在環境中實驗一把了。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Xj-HDFqTGU3qoVBCRkjM9g