日誌系統新貴Loki，真香！

做者：linkt1234git

原文：https://blog.csdn.net/Linkthaha/article/details/100575278github

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

背景和動機數據庫

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

咱們的監控使用的是基於 Prometheus 體系進行改造的，Prometheus 中比較重要的是 Metric 和 Alert。微信

Metric 是來講明當前或者歷史達到了某個值，Alert 設置 Metric 達到某個特定的基數觸發了告警，可是這些信息明顯是不夠的。架構

咱們都知道，Kubernetes 的基本單位是 Pod，Pod 把日誌輸出到 stdout 和 stderr，平時有什麼問題咱們一般在界面或者經過命令查看相關的日誌。app

舉個例子：當咱們的某個 Pod 的內存變得很大，觸發了咱們的 Alert，這個時候管理員，去頁面查詢確認是哪一個 Pod 有問題，而後要確認 Pod 內存變大的緣由。分佈式

咱們還須要去查詢 Pod 的日誌，若是沒有日誌系統，那麼咱們就須要到頁面或者使用命令進行查詢了：

若是，這個時候應用忽然掛了，這個時候咱們就沒法查到相關的日誌了，因此須要引入日誌系統，統一收集日誌。spa

而使用 ELK 的話，就須要在 Kibana 和 Grafana 之間切換，影響用戶體驗。.net

因此，Loki 的第一目的就是最小化度量和日誌的切換成本，有助於減小異常事件的響應時間和提升用戶的體驗。

ELK 存在的問題

現有的不少日誌採集的方案都是採用全文檢索對日誌進行索引（如 ELK 方案），優勢是功能豐富，容許複雜的操做。可是，這些方案每每規模複雜，資源佔用高，操做苦難。

不少功能每每用不上，大多數查詢只關注必定時間範圍和一些簡單的參數（如 host、service 等），使用這些解決方案就有點殺雞用牛刀的感受了。

所以，Loki 的第二個目的是，在查詢語言的易操做性和複雜性之間能夠達到一個權衡。

成本

全文檢索的方案也帶來成本問題，簡單的說就是全文搜索（如 ES）的倒排索引的切分和共享的成本較高。

後來出現了其餘不一樣的設計方案如：OKlog（https://github.com/oklog/oklog），採用最終一致的、基於網格的分佈策略。

這兩個設計決策提供了大量的成本下降和很是簡單的操做，可是查詢不夠方便。所以，Loki 的第三個目的是，提升一個更具成本效益的解決方案。

總體架構

Loki 的架構以下：

不難看出，Loki 的架構很是簡單，使用了和 Prometheus 同樣的標籤來做爲索引。

也就是說，你經過這些標籤既能夠查詢日誌的內容也能夠查詢到監控的數據，不但減小了兩種查詢之間的切換成本，也極大地下降了日誌索引的存儲。

Loki 將使用與 Prometheus 相同的服務發現和標籤從新標記庫，編寫了 Pormtail，在 Kubernetes 中 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 已經在實際的生產中投入使用多年了。有了這句話，我能夠放心的在環境中實驗一把了。

END

Kubernetes CKA實戰培訓班推薦：

北京站：8月14-16日

本文分享自微信公衆號 - K8S中文社區（k8schina）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。