企業(yè)級(jí)日志平臺(tái)新秀Loki，比ELK輕量多了~
原文鏈接：http://blog.csdn.net/Linkthaha/article/details/100575651
最近，在對(duì)公司容器云的日志方案進(jìn)行設(shè)計(jì)時(shí)，發(fā)現(xiàn)主流的 ELK 或者 EFK 比較重，再加上現(xiàn)階段對(duì)于 ES 復(fù)雜的搜索功能很多都用不上，最終選擇了 Grafana 開源的 Loki 日志系統(tǒng)，下面介紹下 Loki 的背景。
背景和動(dòng)機(jī)
我們的監(jiān)控使用的是基于 Prometheus 體系進(jìn)行改造的，Prometheus 中比較重要的是 Metric 和 Alert。
Metric 是來(lái)說(shuō)明當(dāng)前或者歷史達(dá)到了某個(gè)值，Alert 設(shè)置 Metric 達(dá)到某個(gè)特定的基數(shù)觸發(fā)了告警，但是這些信息明顯是不夠的。
我們都知道，Kubernetes 的基本單位是 Pod，Pod 把日志輸出到 stdout 和 stderr，平時(shí)有什么問(wèn)題我們通常在界面或者通過(guò)命令查看相關(guān)的日志。
舉個(gè)例子：當(dāng)我們的某個(gè) Pod 的內(nèi)存變得很大，觸發(fā)了我們的 Alert，這個(gè)時(shí)候管理員，去頁(yè)面查詢確認(rèn)是哪個(gè) Pod 有問(wèn)題，然后要確認(rèn) Pod 內(nèi)存變大的原因。
如果，這個(gè)時(shí)候應(yīng)用突然掛了，這個(gè)時(shí)候我們就無(wú)法查到相關(guān)的日志了，所以需要引入日志系統(tǒng)，統(tǒng)一收集日志。
而使用 ELK 的話，就需要在 Kibana 和 Grafana 之間切換，影響用戶體驗(yàn)。
所以 ，Loki 的第一目的就是最小化度量和日志的切換成本，有助于減少異常事件的響應(yīng)時(shí)間和提高用戶的體驗(yàn)。
ELK 存在的問(wèn)題
現(xiàn)有的很多日志采集的方案都是采用全文檢索對(duì)日志進(jìn)行索引（如 ELK 方案），優(yōu)點(diǎn)是功能豐富，允許復(fù)雜的操作。但是，這些方案往往規(guī)模復(fù)雜，資源占用高，操作苦難。
因此，Loki 的第二個(gè)目的是，在查詢語(yǔ)言的易操作性和復(fù)雜性之間可以達(dá)到一個(gè)權(quán)衡。
成本
全文檢索的方案也帶來(lái)成本問(wèn)題，簡(jiǎn)單的說(shuō)就是全文搜索（如 ES）的倒排索引的切分和共享的成本較高。
后來(lái)出現(xiàn)了其他不同的設(shè)計(jì)方案如：OKlog（https://github.com/oklog/oklog），采用最終一致的、基于網(wǎng)格的分布策略。
這兩個(gè)設(shè)計(jì)決策提供了大量的成本降低和非常簡(jiǎn)單的操作，但是查詢不夠方便。因此，Loki 的第三個(gè)目的是，提高一個(gè)更具成本效益的解決方案。
整體架構(gòu)
不難看出，Loki 的架構(gòu)非常簡(jiǎn)單，使用了和 Prometheus 一樣的標(biāo)簽來(lái)作為索引。
也就是說(shuō)，你通過(guò)這些標(biāo)簽既可以查詢?nèi)罩镜膬?nèi)容也可以查詢到監(jiān)控的數(shù)據(jù)，不但減少了兩種查詢之間的切換成本，也極大地降低了日志索引的存儲(chǔ)。
Loki 將使用與 Prometheus 相同的服務(wù)發(fā)現(xiàn)和標(biāo)簽重新標(biāo)記庫(kù)，編寫了 Pormtail，在 Kubernetes 中 Promtail 以 DaemonSet 方式運(yùn)行在每個(gè)節(jié)點(diǎn)中，通過(guò) Kubernetes API 等到日志的正確元數(shù)據(jù)，并將它們發(fā)送到 Loki。
讀寫
日志數(shù)據(jù)的寫主要依托的是 Distributor 和 Ingester 兩個(gè)組件，整體的流程如下：
Distributor
一旦 Promtail 收集日志并將其發(fā)送給 Loki，Distributor 就是第一個(gè)接收日志的組件。
由于日志的寫入量可能很大，所以不能在它們傳入時(shí)將它們寫入數(shù)據(jù)庫(kù)。這會(huì)毀掉數(shù)據(jù)庫(kù)。我們需要批處理和壓縮數(shù)據(jù)。
Loki 通過(guò)構(gòu)建壓縮數(shù)據(jù)塊來(lái)實(shí)現(xiàn)這一點(diǎn)，方法是在日志進(jìn)入時(shí)對(duì)其進(jìn)行 Gzip 操作，組件 Ingester 是一個(gè)有狀態(tài)的組件，負(fù)責(zé)構(gòu)建和刷新 Chunck，當(dāng) Chunk 達(dá)到一定的數(shù)量或者時(shí)間后，刷新到存儲(chǔ)中去。
此外，為了冗余和彈性，我們將其復(fù)制 n（默認(rèn)情況下為 3）次。
Ingester
基本上就是將日志進(jìn)行壓縮并附加到 Chunk 上面。一旦 Chunk“填滿”（數(shù)據(jù)達(dá)到一定數(shù)量或者過(guò)了一定期限），Ingester 將其刷新到數(shù)據(jù)庫(kù)。
刷新一個(gè) Chunk 之后，Ingester 然后創(chuàng)建一個(gè)新的空 Chunk 并將新條目添加到該 Chunk 中。
Querier
讀取就非常簡(jiǎn)單了，由 Querier 負(fù)責(zé)給定一個(gè)時(shí)間范圍和標(biāo)簽選擇器，Querier 查看索引以確定哪些塊匹配，并通過(guò) greps 將結(jié)果顯示出來(lái)。它還從 Ingester 獲取尚未刷新的最新數(shù)據(jù)。
可擴(kuò)展性
Loki 的索引存儲(chǔ)可以是 cassandra/bigtable/dynamodb，而 Chuncks 可以是各種對(duì)象存儲(chǔ)，Querier 和 Distributor 都是無(wú)狀態(tài)的組件。
對(duì)于 Ingester 他雖然是有狀態(tài)的但是，當(dāng)新的節(jié)點(diǎn)加入或者減少，整節(jié)點(diǎn)間的 Chunk 會(huì)重新分配，已適應(yīng)新的散列環(huán)。
而 Loki 底層存儲(chǔ)的實(shí)現(xiàn) Cortex 已經(jīng)在實(shí)際的生產(chǎn)中投入使用多年了。有了這句話，我可以放心的在環(huán)境中實(shí)驗(yàn)一把了。
- END -
公眾號(hào)后臺(tái)回復(fù)「加群」加入一線高級(jí)工程師技術(shù)交流群，一起交流進(jìn)步。
?推薦閱讀? 31天拿下Kubernetes CKA認(rèn)證！ 2021最新 Kubernetes 運(yùn)維架構(gòu)師實(shí)戰(zhàn)指南? Kubernetes Ingress-Nginx 實(shí)現(xiàn)藍(lán)綠、灰度發(fā)布 一文搞懂藍(lán)綠發(fā)布、灰度發(fā)布和滾動(dòng)發(fā)布 Kubernetes 集群網(wǎng)絡(luò)從懵圈到熟悉 一篇文章搞懂日志采集利器 Filebeat Prometheus 監(jiān)控服務(wù)端口、網(wǎng)站狀態(tài)等（黑盒監(jiān)測(cè)） Kubernetes 學(xué)習(xí)筆記總結(jié)，超詳細(xì)！ Kubernetes生產(chǎn)環(huán)境最佳實(shí)踐
點(diǎn)亮，服務(wù)器三年不宕機(jī)
