[[382865]]

前言

筆者最近擔(dān)起了公司監(jiān)控的重任，而當(dāng)前監(jiān)控最流行的數(shù)據(jù)庫(kù)即是Prometheus。按照筆者打破砂鍋問(wèn)到底的精神，自然要把這個(gè)開(kāi)源組件源碼搞明白才行。在經(jīng)過(guò)一系列源碼/資料的閱讀以及各種Debug之后，對(duì)其內(nèi)部機(jī)制有了一定的認(rèn)識(shí)。今天，筆者就來(lái)介紹下Prometheus的存儲(chǔ)結(jié)構(gòu)。

由于篇幅較長(zhǎng)，所以筆者分為兩篇，本篇主要是描述Prometheus監(jiān)控?cái)?shù)據(jù)在內(nèi)存中的存儲(chǔ)結(jié)構(gòu)。下一篇，主要描述的是監(jiān)控?cái)?shù)據(jù)在磁盤(pán)中的存儲(chǔ)結(jié)構(gòu)。

Gorilla

Prometheus的存儲(chǔ)結(jié)構(gòu)-TSDB是參考了Facebook的Gorilla之后，自行實(shí)現(xiàn)的。所以閱讀

這篇文章《Gorilla: A Fast, Scalable, In-Memory Time Series Database》，可以對(duì)Prometheus為何采用這樣的存儲(chǔ)結(jié)構(gòu)有著清晰的理解。

監(jiān)控?cái)?shù)據(jù)點(diǎn)

下面是一個(gè)非常典型的監(jiān)控曲線(xiàn)。

可以觀(guān)察到，監(jiān)控?cái)?shù)據(jù)都是由一個(gè)一個(gè)數(shù)據(jù)點(diǎn)組成，所以可以用下面的結(jié)構(gòu)來(lái)保存最基本的存儲(chǔ)單元

type sample struct { 
    t int64 
    v float64 
} 

同時(shí)我們還需要注意到的信息是，我們需要知道這些點(diǎn)屬于什么機(jī)器的哪種監(jiān)控。這種信息在Promtheus中就用Label(標(biāo)簽來(lái)表示)。一個(gè)監(jiān)控項(xiàng)一般會(huì)有多個(gè)Label(例如圖中)，所以一般用labels []Label。

由于在我們的習(xí)慣中，并不關(guān)心單獨(dú)的點(diǎn)，而是要關(guān)心這段時(shí)間內(nèi)的曲線(xiàn)情況。所以自然而然的，我們存儲(chǔ)結(jié)構(gòu)肯定邏輯上是這個(gè)樣子:

這樣，我們就可以很容易的通過(guò)一個(gè)Labels(標(biāo)簽們)找到對(duì)應(yīng)的數(shù)據(jù)了。

監(jiān)控?cái)?shù)據(jù)在內(nèi)存中的表示形式

最近的數(shù)據(jù)保存在內(nèi)存中

Prometheus將最近的數(shù)據(jù)保存在內(nèi)存中，這樣查詢(xún)最近的數(shù)據(jù)會(huì)變得非?？欤缓笸ㄟ^(guò)一個(gè)compactor定時(shí)將數(shù)據(jù)打包到磁盤(pán)。數(shù)據(jù)在內(nèi)存中最少保留2個(gè)小時(shí)(storage.tsdb.min-block-duration。至于為什么設(shè)置2小時(shí)這個(gè)值，應(yīng)該是Gorilla那篇論文中觀(guān)察得出的結(jié)論

即壓縮率在2小時(shí)時(shí)候達(dá)到最高，如果保留的時(shí)間更短，就無(wú)法最大化的壓縮。

內(nèi)存序列(memSeries)

接下來(lái)，我們看下具體的數(shù)據(jù)結(jié)構(gòu)

type memSeries stuct { 
    ...... 
    ref uint64 // 其id 
    lst labels.Labels // 對(duì)應(yīng)的標(biāo)簽集合 
    chunks []*memChunk // 數(shù)據(jù)集合 
    headChunk *memChunk // 正在被寫(xiě)入的chunk 
    ...... 
} 

其中memChunk是真正保存數(shù)據(jù)的內(nèi)存塊，將在后面講到。我們先來(lái)觀(guān)察下memSeries在內(nèi)存中的組織。

由此我們可以看到，針對(duì)一個(gè)最終端的監(jiān)控項(xiàng)(包含抓取的所有標(biāo)簽，以及新添加的標(biāo)簽,例如ip)，我們都在內(nèi)存有一個(gè)memSeries結(jié)構(gòu)。

尋址memSeries

如果通過(guò)一堆標(biāo)簽快速找到對(duì)應(yīng)的memSeries。自然的,Prometheus就采用了hash。主要結(jié)構(gòu)體為:

type stripeSeries struct { 
    series [stripeSize]map[uint64]*memSeries // 記錄refId到memSeries的映射 
    hashes [stripeSize]seriesHashmap // 記錄hash值到memSeries,hash沖突采用拉鏈法 
    locks  [stripeSize]stripeLock // 分段鎖 
} 
type seriesHashmap map[uint64][]*memSeries 

由于在Prometheus中會(huì)頻繁的對(duì)map[hash/refId]memSeries進(jìn)行操作，例如檢查這個(gè)labelSet對(duì)應(yīng)的memSeries是否存在，不存在則創(chuàng)建等。由于golang的map非線(xiàn)程安全，所以其采用了分段鎖去拆分鎖。

而hash值是依據(jù)labelSets的值而算出來(lái)。

數(shù)據(jù)點(diǎn)的存儲(chǔ)

為了讓Prometheus在內(nèi)存和磁盤(pán)中保存更大的數(shù)據(jù)量，勢(shì)必需要進(jìn)行壓縮。而memChunk在內(nèi)存中保存的正是采用XOR算法壓縮過(guò)的數(shù)據(jù)。在這里，筆者只給出Gorilla論文中的XOR描述

更具體的算法在論文中有詳細(xì)描述?？傊?，使用了XOR算法后，平均每個(gè)數(shù)據(jù)點(diǎn)能從16bytes壓縮到1.37bytes，也就是說(shuō)所用空間直接降為原來(lái)的1/12!

內(nèi)存中的倒排索引

上面討論的是標(biāo)簽全部給出的查詢(xún)情況。那么我們?cè)趺纯焖僬业侥硞€(gè)或某幾個(gè)標(biāo)簽(非全部標(biāo)簽)的數(shù)據(jù)呢。這就需要引入以L(fǎng)abel為key的倒排索引。我們先給出一組標(biāo)簽集合

{__name__:http_requests}{group:canary}{instance:0}{job:api-server}    
{__name__:http_requests}{group:canary}{instance:1}{job:api-server} 
{__name__:http_requests}{group:production}{instance:1}{job,api-server} 
{__name__:http_requests}{group:production}{instance:0}{job,api-server} 

可以看到，由于標(biāo)簽取值不同，我們會(huì)有四種不同的memSeries。如果一次性給定4個(gè)標(biāo)簽，應(yīng)該是很容易從map中直接獲取出對(duì)應(yīng)的memSeries(盡管Prometheus并沒(méi)有這么做)。但大部分我們的promql只是給定了部分標(biāo)簽，如何快速的查找符合標(biāo)簽的數(shù)據(jù)呢?

這就引入倒排索引。

先看一下，上面例子中的memSeries在內(nèi)存中會(huì)有4種，同時(shí)內(nèi)存中還夾雜著其它監(jiān)控項(xiàng)的series

如果我們想知道job:api-server,group為production在一段時(shí)間內(nèi)所有的http請(qǐng)求數(shù)量,那么必須獲取標(biāo)簽攜帶

({__name__:http_requests}{job:api-server}{group:production})的所有監(jiān)控?cái)?shù)據(jù)。

如果沒(méi)有倒排索引，那么我們必須遍歷內(nèi)存中所有的memSeries(數(shù)萬(wàn)乃至數(shù)十萬(wàn))，一一按照Labels去比對(duì),這顯然在性能上是不可接受的。而有了倒排索引，我們就可以通過(guò)求交集的手段迅速的獲取需要哪些memSeries。

注意，這邊倒排索引存儲(chǔ)的refId必須是有序的。這樣，我們就可以在O(n)復(fù)雜度下順利的算出交集,另外，針對(duì)其它請(qǐng)求形式，還有并集/差集的操作,對(duì)應(yīng)實(shí)現(xiàn)結(jié)構(gòu)體為:

type intersectPostings struct {...}  // 交集 
type mergedPostings struct {...} // 并集 
type removedPostings struct {...} // 差集 

倒排索引的插入組織即為Prometheus下面的代碼

Add(labels,t,v)  
    |->getOrCreateWithID 
        |->memPostings.Add 
 
// Add a label set to the postings index. 
func (p *MemPostings) Add(id uint64, lset labels.Labels) { 
    p.mtx.Lock() 
    // 將新創(chuàng)建的memSeries refId都加到對(duì)應(yīng)的Label倒排里去 
    for _, l := range lset { 
        p.addFor(id, l) 
    } 
    p.addFor(id, allPostingsKey) // allPostingKey "","" every one都加進(jìn)去 
 
    p.mtx.Unlock() 
} 

正則支持

事實(shí)上，給定特定的Label:Value還是無(wú)法滿(mǎn)足我們的需求。我們還需要對(duì)標(biāo)簽正則化，例如取出所有ip為1.1.*前綴的http_requests監(jiān)控?cái)?shù)據(jù)。為了這種正則，Prometheus還維護(hù)了一個(gè)標(biāo)簽所有可能的取值。對(duì)應(yīng)代碼為:

Add(labels,t,v)  
    |->getOrCreateWithID 
        |->memPostings.Add 
func (h *Head) getOrCreateWithID(id, hash uint64, lset labels.Labels){ 
    ... 
    for _, l := range lset { 
        valset, ok := h.values[l.Name] 
        if !ok { 
            valset = stringset{} 
            h.values[l.Name] = valset 
        } 
        // 將可能取值塞入stringset中 
        valset.set(l.Value) 
        // 符號(hào)表的維護(hù) 
        h.symbols[l.Name] = struct{}{} 
        h.symbols[l.Value] = struct{}{} 
    } 
    ... 
} 

那么，在內(nèi)存中，我們就有了如下的表

圖中所示，有了label和對(duì)應(yīng)所有value集合的表，一個(gè)正則請(qǐng)求就可以很容的分解為若干個(gè)非正則請(qǐng)求并最后求交/并/查集，即可得到最終的結(jié)果。

總結(jié)

Prometheus作為當(dāng)今最流行的時(shí)序數(shù)據(jù)庫(kù)，其中有非常多的值得我們借鑒的設(shè)計(jì)和機(jī)制。這一篇筆者主要描述了監(jiān)控?cái)?shù)據(jù)在內(nèi)存中的存儲(chǔ)結(jié)構(gòu)。下一篇，將會(huì)闡述監(jiān)控?cái)?shù)據(jù)在磁盤(pán)中的存儲(chǔ)結(jié)構(gòu)，敬請(qǐng)期待!

本文轉(zhuǎn)載自微信公眾號(hào)「解Bug之路」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系解Bug之路公眾號(hào)。