本文轉(zhuǎn)載自解bug之路 作者alchemystarlzy
前言
之前的文章里，筆者詳細(xì)描述了監(jiān)控?cái)?shù)據(jù)在Prometheus內(nèi)存中的結(jié)構(gòu)。而其在磁盤中的存儲結(jié)構(gòu)厨埋，也是非常有意思的,關(guān)于這部分內(nèi)容撤缴，將在本篇文章進(jìn)行闡述。
磁盤目錄結(jié)構(gòu)
首先我們來看Prometheus運(yùn)行后令蛉，所形成的文件目錄結(jié)構(gòu)
在筆者自己的機(jī)器上的具體結(jié)構(gòu)如下:
prometheus-data????|-01EY0EH5JA3ABCB0PXHAPP999D?(block)????|-01EY0EH5JA3QCQB0PXHAPP999D?(block)????????|-chunks????????????|-000001????????????|-000002????????????.....????????????|-000021????????|-index????????|-meta.json????????|-tombstones????|-wal????|-chunks_head
Block
一個(gè)Block就是一個(gè)獨(dú)立的小型數(shù)據(jù)庫聚霜，其保存了一段時(shí)間內(nèi)所有查詢所用到的信息。包括標(biāo)簽/索引/符號表數(shù)據(jù)等等珠叔。Block的實(shí)質(zhì)就是將一段時(shí)間里的內(nèi)存數(shù)據(jù)組織成文件形式保存下來蝎宇。
最近的Block一般是存儲了2小時(shí)的數(shù)據(jù)，而較為久遠(yuǎn)的Block則會通過compactor進(jìn)行合并祷安，一個(gè)Block可能存儲了若干小時(shí)的信息姥芥。值得注意的是，合并操作只是減少了索引的大小(尤其是符號表的合并)汇鞭，而本身數(shù)據(jù)(chunks)的大小并沒有任何改變凉唐。
meta.json
我們可以通過檢查meta.json來得到當(dāng)前Block的一些元信息庸追。
{????"ulid":"01EY0EH5JA3QCQB0PXHAPP999D"????//?maxTime-minTime?=?7200s?=>?2?h????"minTime":?1611664000000????"maxTime":?1611671200000????"stats":?{????????"numSamples":?1505855631,????????"numSeries":?12063563,????????"numChunks":?12063563????}????"compaction":{????????"level"?:?1????????"sources:?[????????????"01EY0EH5JA3QCQB0PXHAPP999D"????????]????}????"version":1}其中的元信息非常清楚明了。這個(gè)Block記錄了2個(gè)小時(shí)的數(shù)據(jù)台囱。
讓我們再找一個(gè)比較陳舊的Block看下它的meta.json.
????"ulid":"01EXTEH5JA3QCQB0PXHAPP999D",????//?maxTime?-?maxTime?=>162h????"minTime":1610964800000,????"maxTime":1611548000000????......????"compaction":{????????"level":?5,????????"sources:?[????????????31個(gè)01EX......????????]????},????"parents:?[????????{????????????????"ulid":?01EXTEH5JA3QCQB1PXHAPP999D????????????...????????}????????{????????????????"ulid":?01EXTEH6JA3QCQB1PXHAPP999D????????????...????????}????????????????{????????????????"ulid":?01EXTEH5JA31CQB1PXHAPP999D????????????...????????}????]從中我們可以看到淡溯，該Block是由31個(gè)原始Block經(jīng)歷5次壓縮而來。最后一次壓縮的三個(gè)Block ulid記錄在parents中簿训。如下圖所示:
Chunks結(jié)構(gòu)
CUT文件切分
所有的Chunk文件在磁盤上都不會大于512M,對應(yīng)的源碼為:
func?(w?*Writer)?WriteChunks(chks?...Meta)?error?{????......????for?i,?chk?:=?range?chks?{????????cutNewBatch?:=?(i?!=?0)?&&?(batchSize+SegmentHeaderSize?>?w.segmentSize)????????......????????if?cutNewBatch?{????????????......????????}????????......????}}當(dāng)寫入磁盤單個(gè)文件超過512M的時(shí)候咱娶，就會自動(dòng)切分一個(gè)新的文件。
一個(gè)Chunks文件包含了非常多的內(nèi)存Chunk結(jié)構(gòu),如下圖所示:
圖中也標(biāo)出了强品，我們是怎么尋找對應(yīng)Chunk的膘侮。通過將文件名(000001，前32位)以及(offset,后32位)編碼到一個(gè)int類型的refId中择懂，使得我們可以輕松的通過這個(gè)id獲取到對應(yīng)的chunk數(shù)據(jù)喻喳。
chunks文件通過mmap去訪問
由于chunks文件大小基本固定(最大512M),所以我們很容易的可以通過mmap去訪問對應(yīng)的數(shù)據(jù)。直接將對應(yīng)文件的讀操作交給操作系統(tǒng)困曙，既省心又省力表伦。對應(yīng)代碼為:
func?NewDirReader(dir?string,?pool?chunkenc.Pool)?(*Reader,?error)?{????......????for?_,?fn?:=?range?files?{????????f,?err?:=?fileutil.OpenMmapFile(fn)????????......????}????......????bs?=?append(bs,?realByteSlice(f.Bytes()))}通過sgmBytes?:=?s.bs[offset]就直接能獲取對應(yīng)的數(shù)據(jù)
index索引結(jié)構(gòu)
前面介紹完chunk文件，我們就可以開始闡述最復(fù)雜的索引結(jié)構(gòu)了慷丽。
尋址過程
索引就是為了讓我們快速的找到想要的內(nèi)容蹦哼，為了便于理解。筆者就通過一次數(shù)據(jù)的尋址來探究Prometheus的磁盤索引結(jié)構(gòu)要糊「傺考慮查詢一個(gè)
擁有系列三個(gè)標(biāo)簽({__name__:http_requests}{job:api-server}{instance:0})且時(shí)間為start/end的所有序列數(shù)據(jù)我們先從選擇Block開始,遍歷所有Block的meta.json，找到具體的Block
前文說了锄俄，通過Labels找數(shù)據(jù)是通過倒排索引局劲。我們的倒排索引是保存在index文件里面的。那么怎么在這個(gè)單一文件里找到倒排索引的位置呢奶赠？這就引入了TOC(Table Of Content)
TOC(Table Of Content)
由于index文件一旦形成之后就不再會改變鱼填，所以Prometheus也依舊使用mmap來進(jìn)行操作。采用mmap讀取TOC非常容易:
func?NewTOCFromByteSlice(bs?ByteSlice)?(*TOC,?error)?{????......????//?indexTOCLen?=?6*8+4?=?52????b?:=?bs.Range(bs.Len()-indexTOCLen,?bs.Len())????......????return?&TOC{????????Symbols:???????????d.Be64(),????????Series:????????????d.Be64(),????????LabelIndices:??????d.Be64(),????????LabelIndicesTable:?d.Be64(),????????Postings:??????????d.Be64(),????????PostingsTable:?????d.Be64(),????},?nil}Posting offset table 以及 Posting倒排索引
首先我們訪問的是Posting offset table毅戈。由于倒排索引按照不同的LabelPair(key/value)會有非常多的條目苹丸。所以Posing offset table就是決定到底訪問哪一條Posting索引。offset就是指的這一Posting條目在文件中的偏移苇经。
Series
我們通過三條Postings倒排索引索引取交集得出
{series1,Series2,Series3,Series4}∩{series1,Series2,Series3}∩{Series2,Series3}={Series2,Series3}也就是要讀取Series2和Serie3中的數(shù)據(jù)赘理，而Posting中的Ref(Series2)和Ref(Series3)即為這兩Series在index文件中的偏移。
Series以Delta的形式記錄了chunkId以及該chunk包含的時(shí)間范圍扇单。這樣就可以很容易過濾出我們需要的chunk,然后再按照chunk文件的訪問商模，即可找到最終的原始數(shù)據(jù)。
SymbolTable
值得注意的是，為了盡量減少我們文件的大小施流，對于Label的Name和Value這些有限的數(shù)據(jù)凉倚，我們會按照字母序存在符號表中。由于是有序的嫂沉，所以我們可以直接將符號表認(rèn)為是一個(gè)
[]string切片稽寒。然后通過切片的下標(biāo)去獲取對應(yīng)的sting√苏拢考慮如下符號表:
讀取index文件時(shí)候杏糙，會將SymbolTable全部加載到內(nèi)存中，并組織成symbols []string這樣的切片形式蚓土，這樣一個(gè)Series中的所有標(biāo)簽值即可通過切片下標(biāo)訪問得到宏侍。
Label Index以及Label Table
事實(shí)上，前面的介紹已經(jīng)將一個(gè)普通數(shù)據(jù)尋址的過程全部講完了蜀漆。但是index文件中還包含label索引以及l(fā)abel Table谅河，這兩個(gè)是用來記錄一個(gè)Label下面所有可能的值而存在的。
這樣确丢，在正則的時(shí)候就可以非常容易的找到我們需要哪些LabelPair绷耍。詳情可以見前篇。
事實(shí)上鲜侥，真正的Label Index比圖中要復(fù)雜一點(diǎn)褂始。它設(shè)計(jì)成一條LabelIndex可以表示(多個(gè)標(biāo)簽組合)的所有數(shù)據(jù)。不過在Prometheus代碼中只會采用存儲一個(gè)標(biāo)簽對應(yīng)所有值的形式描函。
完整的index文件結(jié)構(gòu)
這里直接給出完整的index文件結(jié)構(gòu)崎苗，摘自Prometheus中index.md文檔。
┌────────────────────────────┬─────────────────────┐│?magic(0xBAAAD700)?<4b>?????│?version(1)?<1?byte>?│├────────────────────────────┴─────────────────────┤│?┌──────────────────────────────────────────────┐?││?│?????????????????Symbol?Table?????????????????│?││?├──────────────────────────────────────────────┤?││?│????????????????????Series????????????????????│?││?├──────────────────────────────────────────────┤?││?│?????????????????Label?Index?1????????????????│?││?├──────────────────────────────────────────────┤?││?│??????????????????????...?????????????????????│?││?├──────────────────────────────────────────────┤?││?│?????????????????Label?Index?N????????????????│?││?├──────────────────────────────────────────────┤?││?│???????????????????Postings?1?????????????????│?││?├──────────────────────────────────────────────┤?││?│??????????????????????...?????????????????????│?││?├──────────────────────────────────────────────┤?││?│???????????????????Postings?N?????????????????│?││?├──────────────────────────────────────────────┤?││?│???????????????Label?Index?Table??????????????│?││?├──────────────────────────────────────────────┤?││?│?????????????????Postings?Table???????????????│?││?├──────────────────────────────────────────────┤?││?│??????????????????????TOC?????????????????????│?││?└──────────────────────────────────────────────┘?│└──────────────────────────────────────────────────┘
tombstones
由于Prometheus Block的數(shù)據(jù)一般在寫完后就不會變動(dòng)舀寓。如果要?jiǎng)h除部分?jǐn)?shù)據(jù)胆数，就只能記錄一下刪除數(shù)據(jù)的范圍，由下一次compactor組成新block的時(shí)候刪除互墓。而記錄這些信息的文件即是tomstones必尼。
Prometheus入門書籍推薦
總結(jié)
Prometheus作為時(shí)序數(shù)據(jù)庫，設(shè)計(jì)了各種文件結(jié)構(gòu)來保存海量的監(jiān)控?cái)?shù)據(jù)轰豆，同時(shí)還兼顧了性能胰伍。只有徹底了解其存儲結(jié)構(gòu)齿诞，才能更好的指導(dǎo)我們應(yīng)用它酸休！
歡迎大家關(guān)注我公眾號，里面有各種干貨祷杈，還有大禮包相送哦!
