作者：linkt1234
轉(zhuǎn)自：51CTO
出處：http://blog.csdn.net/Linkthaha/article/details/100575651

背景和動機(jī)

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

image

我們的監(jiān)控使用的是基于 Prometheus 體系進(jìn)行改造的宰掉，Prometheus 中比較重要的是 Metric 和 Alert呵哨。

Metric 是來說明當(dāng)前或者歷史達(dá)到了某個值赁濒，Alert 設(shè)置 Metric 達(dá)到某個特定的基數(shù)觸發(fā)了告警，但是這些信息明顯是不夠的孟害。

我們都知道拒炎，Kubernetes 的基本單位是 Pod，Pod 把日志輸出到 stdout 和 stderr纹坐，平時有什么問題我們通常在界面或者通過命令查看相關(guān)的日志枝冀。

舉個例子：當(dāng)我們的某個 Pod 的內(nèi)存變得很大，觸發(fā)了我們的 Alert耘子，這個時候管理員果漾，去頁面查詢確認(rèn)是哪個 Pod 有問題，然后要確認(rèn) Pod 內(nèi)存變大的原因谷誓。

我們還需要去查詢 Pod 的日志绒障，如果沒有日志系統(tǒng)，那么我們就需要到頁面或者使用命令進(jìn)行查詢了：

image

如果捍歪，這個時候應(yīng)用突然掛了户辱，這個時候我們就無法查到相關(guān)的日志了，所以需要引入日志系統(tǒng)糙臼，統(tǒng)一收集日志庐镐。

而使用 ELK 的話，就需要在 Kibana 和 Grafana 之間切換变逃，影響用戶體驗必逆。

所以 ，Loki 的第一目的就是最小化度量和日志的切換成本揽乱，有助于減少異常事件的響應(yīng)時間和提高用戶的體驗名眉。

ELK 存在的問題

現(xiàn)有的很多日志采集的方案都是采用全文檢索對日志進(jìn)行索引（如 ELK 方案），優(yōu)點(diǎn)是功能豐富凰棉，允許復(fù)雜的操作损拢。但是，這些方案往往規(guī)模復(fù)雜撒犀，資源占用高福压，操作苦難。

很多功能往往用不上或舞，大多數(shù)查詢只關(guān)注一定時間范圍和一些簡單的參數(shù)（如 host隧膏、service 等），使用這些解決方案就有點(diǎn)殺雞用牛刀的感覺了嚷那。

image

因此胞枕，Loki 的第二個目的是，在查詢語言的易操作性和復(fù)雜性之間可以達(dá)到一個權(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 一樣的標(biāo)簽來作為索引撕阎。

也就是說受裹，你通過這些標(biāo)簽既可以查詢?nèi)罩镜膬?nèi)容也可以查詢到監(jiān)控的數(shù)據(jù)，不但減少了兩種查詢之間的切換成本虏束，也極大地降低了日志索引的存儲棉饶。

Loki 將使用與 Prometheus 相同的服務(wù)發(fā)現(xiàn)和標(biāo)簽重新標(biāo)記庫，編寫了 Pormtail镇匀，在 Kubernetes 中 Promtail 以 DaemonSet 方式運(yùn)行在每個節(jié)點(diǎn)中照藻，通過 Kubernetes API 等到日志的正確元數(shù)據(jù)，并將它們發(fā)送到 Loki汗侵。

image

讀寫

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

image

Distributor

一旦 Promtail 收集日志并將其發(fā)送給 Loki，Distributor 就是第一個接收日志的組件晃择。

由于日志的寫入量可能很大冀值，所以不能在它們傳入時將它們寫入數(shù)據(jù)庫也物。這會毀掉數(shù)據(jù)庫宫屠。我們需要批處理和壓縮數(shù)據(jù)。

Loki 通過構(gòu)建壓縮數(shù)據(jù)塊來實現(xiàn)這一點(diǎn)滑蚯，方法是在日志進(jìn)入時對其進(jìn)行 Gzip 操作浪蹂，組件 Ingester 是一個有狀態(tài)的組件，負(fù)責(zé)構(gòu)建和刷新 Chunck告材，當(dāng) Chunk 達(dá)到一定的數(shù)量或者時間后坤次，刷新到存儲中去。

image

此外疤剑，為了冗余和彈性滑绒，我們將其復(fù)制 n（默認(rèn)情況下為 3）次闷堡。

Ingester

image

基本上就是將日志進(jìn)行壓縮并附加到 Chunk 上面。一旦 Chunk“填滿”（數(shù)據(jù)達(dá)到一定數(shù)量或者過了一定期限）疑故，Ingester 將其刷新到數(shù)據(jù)庫杠览。

我們對塊和索引使用單獨(dú)的數(shù)據(jù)庫，因為它們存儲的數(shù)據(jù)類型不同纵势。

image

刷新一個 Chunk 之后踱阿，Ingester 然后創(chuàng)建一個新的空 Chunk 并將新條目添加到該 Chunk 中。

Querier

讀取就非常簡單了钦铁，由 Querier 負(fù)責(zé)給定一個時間范圍和標(biāo)簽選擇器软舌，Querier 查看索引以確定哪些塊匹配，并通過 greps 將結(jié)果顯示出來育瓜。它還從 Ingester 獲取尚未刷新的最新數(shù)據(jù)葫隙。

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

image

可擴(kuò)展性

Loki 的索引存儲可以是 cassandra/bigtable/dynamodb糟描，而 Chuncks 可以是各種對象存儲，Querier 和 Distributor 都是無狀態(tài)的組件书妻。

對于 Ingester 他雖然是有狀態(tài)的但是船响，當(dāng)新的節(jié)點(diǎn)加入或者減少，整節(jié)點(diǎn)間的 Chunk 會重新分配躲履，已適應(yīng)新的散列環(huán)见间。

而 Loki 底層存儲的實現(xiàn) Cortex 已經(jīng)在實際的生產(chǎn)中投入使用多年了。有了這句話工猜，我可以放心的在環(huán)境中實驗一把了米诉。