與其他日志系統(tǒng)相比, Loki 的使用方式是有一定差異性的,需要用不同的思維方式。本文分享一下這些差異以及我們應(yīng)該如何使用
作為 Loki 用戶或操作人員,我們目標(biāo)應(yīng)該是使用盡可能少的標(biāo)簽來存儲日志。
更少的標(biāo)簽則意味著更小的索引,從而能帶來更好的性能。
以上這些話聽起來可能覺得有問題。因為在我們以往工作中比如使用 elk、數(shù)據(jù)庫的經(jīng)驗告訴我們,如果想讓它更快,需要對其建立索引。而Loki 是以完全相反的方式構(gòu)建和優(yōu)化的, Loki 的設(shè)計目標(biāo)是保持較低的運營成本和復(fù)雜性,這是通過保持非常小的索引并利用商用硬件性能和并行化查詢來實現(xiàn)的。
因此,作為 Loki 的用戶或操作員,在添加標(biāo)簽之前我一定要三思而后行。
ts=2020-08-25T16:55:42.986960888Z caller=spanlogger.go:53 org_id=29 traceID=2612c3ff044b7d02 method=Store.lookupIdsByMetricNameMatcher level=debug matcher="pod=/"loki-canary-25f2k/"" queries=16
我們可能會想,應(yīng)該提取traceID作為標(biāo)簽,然后可以這樣查詢:
{cluster="ops-cluster-1",namespace="loki-dev", traceID=”2612c3ff044b7d02”}
但不建議這么做,這種方式會導(dǎo)致Loki 查詢效率很低,因為它的值就是個無界的,每次請求都會產(chǎn)生新的traceID,這種情況屬于典型無界的動態(tài)標(biāo)簽值,在Loki里面用Cardinality來表示,Cardinality值越高,Loki的查詢效率越低。如果想在日志中查找高基數(shù)數(shù)據(jù),請使用如下過濾表達(dá)式:
{cluster="ops-cluster-1",namespace="loki-dev"} |= “traceID=2612c3ff044b7d02”
比如日志級別,只有幾個固定值:
{cluster="ops-cluster-1",namespace="loki-dev", level=”debug”}
這里也要注意!因為標(biāo)簽對索引和存儲具有倍增效應(yīng),剛開始的一個日志流,如果使用日志級別標(biāo)簽后,現(xiàn)在已變成4個日志流,所以在我們添加標(biāo)簽時要考慮這些,以下是一個示意圖
靜態(tài)標(biāo)簽開銷更小,在發(fā)送到Loki之前,就會獲取相關(guān) lablel,在k8s 中通過 helm 部署,默認(rèn)采集以下靜態(tài)標(biāo)簽
使用大量數(shù)值的標(biāo)簽是不好的,那么我們?nèi)绾尾樵內(nèi)罩荆咳绻麤]有日志沒有索引,查詢能快嗎?
在我們使用ELK 或者其他日志系統(tǒng)時,我們會創(chuàng)建大量的索引來提高查詢速度,但是在 loki 中我們需要忘記這些東西
因為loki 是通過并行化的方式來提交查詢速度的。
Loki 的超能力是將查詢分解成小塊,并將其并行調(diào)度,這樣就可以在小時間內(nèi)查詢大量的日志數(shù)據(jù),最后在進(jìn)行匯總返回
Loki 利用水平擴(kuò)展和查詢時間來查詢我們的數(shù)據(jù)。這與使用多索引的解決方案一樣快嗎?可能不是!但它運行和部署要容易很多,而且還省資源。
Grafana Lab 的 Loki 部分集群的數(shù)據(jù),在過去 7 天內(nèi),它攝入了 14TB 的數(shù)據(jù)。該時間段對應(yīng)的索引使用量約為500MB;14TB 日志的索引可以放入樹莓派的內(nèi)存中。
這就是為什么Loki專注于保持標(biāo)簽集較小的原因。也許標(biāo)簽只能將搜索范圍縮小到 100GB 的日志數(shù)據(jù) —但是運行 20 個查詢器(可以以 30GB/s 的速度并行搜索 100GB 數(shù)據(jù))比維護(hù)一個 14TB 索引要便宜得多,尤其是當(dāng)我們使用不了幾次的時候。
因此,更少的標(biāo)簽 = 更好的性能。
本文鏈接:http://www.www897cc.com/showinfo-26-73319-0.html日志分析系統(tǒng)Loki使用指南&封面紅包領(lǐng)取
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: React與Vue:事件委托的背后邏輯