用了日誌系統新貴Loki，ELK突然不香了！
“
最近，在對公司容器雲的日誌方案進行設計時，發現主流的 ELK 或者 EFK 比較重，再加上現階段對於 ES 複雜的搜索功能很多都用不上，最終選擇了 Grafana 開源的 Loki 日誌系統，下面介紹下 Loki 的背景。
圖片來自 Pexels
背景和動機
當我們的容器雲運行的應用或者某個節點出現問題了，解決思路應該如下：
我們的監控使用的是基於 Prometheus 體系進行改造的，Prometheus 中比較重要的是 Metric 和 Alert。
Metric 是來說明當前或者歷史達到了某個值，Alert 設置 Metric 達到某個特定的基數觸發了告警，但是這些信息明顯是不夠的。
我們都知道，Kubernetes 的基本單位是 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，在 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 已經在實際的生產中投入使用多年了。有了這句話，我可以放心的在環境中實驗一把了。
作者：linkt1234
編輯： 陶家龍
出處： http://blog.csdn.net/Linkthaha/article/details/100575651
往期 精彩 回顧
.NET Core實戰項目之CMS 第一章 入門篇-開篇及總體規劃
【.NET Core微服務實戰-統一身份認證】開篇及目錄索引
Redis基本使用及百億數據量中的使用技巧分享（附視頻地址及觀看指南）
.NET Core中的一個接口多種實現的依賴注入與動態選擇看這篇就夠了
用abp vNext快速開發Quartz.NET定時任務管理界面
給我好看
您看此文用
·
秒，轉發只需1秒呦~
好看你就
點點
我
