最近，在對公司容器雲的日志方案進行設計的時候，發現主流的elk或者efk比較重，再加上現階段對于es複雜的搜尋功能很多都用不上最終選擇了grafana開源的loki日志系統，下面介紹下loki的背景。
背景和動機
當我們的容器雲運作的應用或者某個節點出現問題了，解決思路應該如下：
我們的監控使用的是基于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，采用最終一緻的、基于網格的分布政策。這兩個設計決策提供了大量的成本降低和非常簡單的操作，但是查詢不夠友善。是以，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已經 在實際的生産中投入使用多年了。有了這句話，我可以放心的在環境中實驗一把了。
部署
loki的安裝非常簡單。
建立namespace
權限設定
安裝loki
安裝指令：
statefulset.json如下：
安裝promtail
configmap.json如下：
daemonset.json如下：
安裝服務
service.json的内容如下：
文法
loki提供了http接口，我們這裡就不詳解了，大家可以看：https://github.com/grafana/loki/blob/master/docs/api.md
我們這裡說下查詢的接口如何使用。
第一步，擷取目前loki的中繼資料類型：
第二步，擷取某個中繼資料類型的值：
第三步，根據label進行查詢，例如：
參數解析：
query：一種查詢文法詳細見下面章節，{name=~“mysql.+”} or {namespace=“cicd”} |= "error"表示查詢，namespace為ci/cd的日志中，有error字樣的資訊。
limit：傳回日志的數量
start：開始時間，unix時間表示方法 預設為，一小時前時間
end：結束時間，預設為目前時間
direction：forward或者backward，指定limit時候有用，預設為 backward
regexp：對結果進行regex過濾
logql文法
選擇器
對于查詢表達式的标簽部分，将放在{}中，多個标簽表達式用逗号分隔：
支援的符号有：
=：完全相同。
!=：不平等。
=~：正規表達式比對。
!~：不要正規表達式比對。
過濾表達式
編寫日志流選擇器後，您可以通過編寫搜尋表達式進一步過濾結果。搜尋表達式可以文本或正規表達式。
如：
{job=“mysql”} |= “error”
{name=“kafka”} |~ “tsdb-ops.*io:2003”
{instance=~“kafka-[23]”,name=“kafka”} != kafka.server:type=replicamanager
支援多個過濾：
{job=“mysql”} |= “error” != “timeout”
目前支援的操作符：
|= line包含字元串。
!= line不包含字元串。
|~ line比對正規表達式。
!~ line與正規表達式不比對。
表達式遵循https://github.com/google/re2/wiki/syntax文法。