來自：CSDN,画切，作者：linkt1234

鏈接：https://blog.csdn.net/Linkthaha/article/details/100575278

最近帜平，在對公司容器云的日志方案進行設(shè)計的時候吟温，發(fā)現(xiàn)主流的ELK或者EFK比較重序仙，再加上現(xiàn)階段對于ES復(fù)雜的搜索功能很多都用不上最終選擇了Grafana開源的Loki日志系統(tǒng)栖茉，下面介紹下Loki的背景姐叁。

image

背景和動機

當(dāng)我們的容器云運行的應(yīng)用或者某個節(jié)點出現(xiàn)問題了，解決思路應(yīng)該如下：

image

我們的監(jiān)控使用的是基于prometheus體系進行改造的嗤栓，prometheus中比較重要的是metric和alert,metric是來說明當(dāng)前或者歷史達到了某個值爬橡，alert設(shè)置metric達到某個特定的基數(shù)觸發(fā)了告警治唤，但是這些信息明顯是不夠的。我們都知道糙申，k8s的基本單位是pod,pod把日志輸出到stdout和stderr,平時有什么問題我們通常在界面或者通過命令查看相關(guān)的日志,舉個例子：當(dāng)我們的某個pod的內(nèi)存變得很大宾添，觸發(fā)了我們的alert，這個時候管理員柜裸，去頁面查詢確認是哪個pod有問題缕陕，然后要確認pod內(nèi)存變大的原因，我們還需要去查詢pod的日志疙挺，如果沒有日志系統(tǒng)扛邑，那么我們就需要到頁面或者使用命令進行查詢了：

image

如果，這個時候應(yīng)用突然掛了铐然，這個時候我們就無法查到相關(guān)的日志了蔬崩，所以需要引入日志系統(tǒng)，統(tǒng)一收集日志搀暑，而使用ELK的話沥阳，就需要在Kibana和Grafana之間切換，影響用戶體驗自点。所以 桐罕，loki的第一目的就是最小化度量和日志的切換成本，有助于減少異常事件的響應(yīng)時間和提高用戶的體驗

ELK存在的問題

現(xiàn)有的很多日志采集的方案都是采用全文檢索對日志進行索引（如ELK方案）桂敛，優(yōu)點是功能豐富冈绊，允許復(fù)雜的操作。但是埠啃，這些方案往往規(guī)模復(fù)雜死宣，資源占用高，操作苦難碴开。很多功能往往用不上毅该，大多數(shù)查詢只關(guān)注一定時間范圍和一些簡單的參數(shù)（如host、service等）潦牛，使用這些解決方案就有點殺雞用牛刀的感覺了眶掌。

image

因此，Loki的第二個目的是巴碗，在查詢語言的易操作性和復(fù)雜性之間可以達到一個權(quán)衡朴爬。

成本

全文檢索的方案也帶來成本問題，簡單的說就是全文搜索（如ES）的倒排索引的切分和共享的成本較高橡淆。后來出現(xiàn)了其他不同的設(shè)計方案如：OKlog(https://github.com/oklog/oklog),采用最終一致的召噩、基于網(wǎng)格的分布策略母赵。這兩個設(shè)計決策提供了大量的成本降低和非常簡單的操作，但是查詢不夠方便具滴。因此凹嘲，Loki的第三個目的是，提高一個更具成本效益的解決方案构韵。

整體架構(gòu)

Loki的架構(gòu)如下：

image

不難看出周蹭，Loki的架構(gòu)非常簡單，使用了和prometheus一樣的標簽來作為索引疲恢，也就是說凶朗，你通過這些標簽既可以查詢?nèi)罩镜膬?nèi)容也可以查詢到監(jiān)控的數(shù)據(jù)，不但減少了兩種查詢之間的切換成本显拳，也極大地降低了日志索引的存儲俱尼。Loki將使用與prometheus相同的服務(wù)發(fā)現(xiàn)和標簽重新標記庫,編寫了pormtail, 在k8s中promtail以daemonset方式運行在每個節(jié)點中，通過kubernetes api等到日志的正確元數(shù)據(jù)萎攒，并將它們發(fā)送到Loki遇八。下面是日志的存儲架構(gòu)：

image

讀寫

日志數(shù)據(jù)的寫主要依托的是Distributor和Ingester兩個組件,整體的流程如下：

image

Distributor

一旦promtail收集日志并將其發(fā)送給loki，Distributor就是第一個接收日志的組件耍休。由于日志的寫入量可能很大刃永，所以不能在它們傳入時將它們寫入數(shù)據(jù)庫。這會毀掉數(shù)據(jù)庫羊精。我們需要批處理和壓縮數(shù)據(jù)斯够。

Loki通過構(gòu)建壓縮數(shù)據(jù)塊來實現(xiàn)這一點，方法是在日志進入時對其進行g(shù)zip操作喧锦，組件ingester是一個有狀態(tài)的組件读规，負責(zé)構(gòu)建和刷新chunck，當(dāng)chunk達到一定的數(shù)量或者時間后燃少，刷新到存儲中去束亏。每個流的日志對應(yīng)一個ingester,當(dāng)日志到達Distributor后，根據(jù)元數(shù)據(jù)和hash算法計算出應(yīng)該到哪個ingester上面阵具。

image

此外碍遍，為了冗余和彈性，我們將其復(fù)制n（默認情況下為3）次阳液。

Ingester

ingester接收到日志并開始構(gòu)建chunk:

image

基本上就是將日志進行壓縮并附加到chunk上面怕敬。一旦chunk“填滿”（數(shù)據(jù)達到一定數(shù)量或者過了一定期限），ingester將其刷新到數(shù)據(jù)庫帘皿。我們對塊和索引使用單獨的數(shù)據(jù)庫东跪，因為它們存儲的數(shù)據(jù)類型不同。

image

刷新一個chunk之后，ingester然后創(chuàng)建一個新的空chunk并將新條目添加到該chunk中虽填。

Querier

讀取就非常簡單了丁恭，由Querier負責(zé)給定一個時間范圍和標簽選擇器，Querier查看索引以確定哪些塊匹配卤唉，并通過greps將結(jié)果顯示出來涩惑。它還從Ingester獲取尚未刷新的最新數(shù)據(jù)仁期。

對于每個查詢桑驱，一個查詢器將為您顯示所有相關(guān)日志。實現(xiàn)了查詢并行化跛蛋，提供分布式grep熬的，使即使是大型查詢也是足夠的。

image

可擴展性

Loki的索引存儲可以是cassandra/bigtable/dynamodb赊级，而chuncks可以是各種對象存儲押框，Querier和Distributor都是無狀態(tài)的組件。對于ingester他雖然是有狀態(tài)的但是理逊，當(dāng)新的節(jié)點加入或者減少橡伞，整節(jié)點間的chunk會重新分配，已適應(yīng)新的散列環(huán)晋被。而Loki底層存儲的實現(xiàn)Cortex已經(jīng) 在實際的生產(chǎn)中投入使用多年了兑徘。有了這句話，我可以放心的在環(huán)境中實驗一把了羡洛。