摘要：為了解決單節(jié)點(diǎn)存儲(chǔ)的限制，沒有自己實(shí)現(xiàn)集群存儲(chǔ)，而是提供了遠(yuǎn)程讀寫的接口，讓用戶自己選擇合適的時(shí)序數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)的擴(kuò)展性。的其實(shí)是一個(gè)，至于在的另一端是什么類型的時(shí)序數(shù)據(jù)庫(kù)它根本不關(guān)心，如果你愿意，你也可以編寫自己的。

Prometheus提供了本地存儲(chǔ)，即tsdb時(shí)序數(shù)據(jù)庫(kù)，本地存儲(chǔ)給Prometheus帶來(lái)了簡(jiǎn)單高效的使用體驗(yàn)，prometheus2.0以后壓縮數(shù)據(jù)能力也得到了很大的提升?？梢栽趩喂?jié)點(diǎn)的情況下滿足大部分用戶的監(jiān)控需求。

但本地存儲(chǔ)也限制了Prometheus的可擴(kuò)展性，帶來(lái)了數(shù)據(jù)持久化等一系列的問題。為了解決單節(jié)點(diǎn)存儲(chǔ)的限制，prometheus沒有自己實(shí)現(xiàn)集群存儲(chǔ)，而是提供了遠(yuǎn)程讀寫的接口，讓用戶自己選擇合適的時(shí)序數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)prometheus的擴(kuò)展性。

Prometheus 1.x版本的TSDB（V2存儲(chǔ)引擎）基于LevelDB，并且使用了和Facebook Gorilla一樣的壓縮算法，能夠?qū)?6個(gè)字節(jié)的數(shù)據(jù)點(diǎn)壓縮到平均1.37個(gè)字節(jié)。

Prometheus 2.x版本引入了全新的V3存儲(chǔ)引擎，提供了更高的寫入和查詢性能

以下所有內(nèi)容均基于prometheus2.7版本

Prometheus按2小時(shí)一個(gè)block進(jìn)行存儲(chǔ)，每個(gè)block由一個(gè)目錄組成，該目錄里包含：一個(gè)或者多個(gè)chunk文件（保存timeseries數(shù)據(jù)）、一個(gè)metadata文件、一個(gè)index文件（通過metric name和labels查找timeseries數(shù)據(jù)在chunk文件的位置）。

最新寫入的數(shù)據(jù)保存在內(nèi)存block中，達(dá)到2小時(shí)后寫入磁盤。為了防止程序崩潰導(dǎo)致數(shù)據(jù)丟失，實(shí)現(xiàn)了WAL（write-ahead-log）機(jī)制，啟動(dòng)時(shí)會(huì)以寫入日志(WAL)的方式來(lái)實(shí)現(xiàn)重播，從而恢復(fù)數(shù)據(jù)。

刪除數(shù)據(jù)時(shí)，刪除條目會(huì)記錄在獨(dú)立的tombstone文件中，而不是立即從chunk文件刪除。

通過時(shí)間窗口的形式保存所有的樣本數(shù)據(jù)，可以明顯提高Prometheus的查詢效率，當(dāng)查詢一段時(shí)間范圍內(nèi)的所有樣本數(shù)據(jù)時(shí)，只需要簡(jiǎn)單的從落在該范圍內(nèi)的塊中查詢數(shù)據(jù)即可。

這些2小時(shí)的block會(huì)在后臺(tái)壓縮成更大的block，數(shù)據(jù)壓縮合并成更高level的block文件后刪除低level的block文件。這個(gè)和leveldb、rocksdb等LSM樹的思路一致。

這些設(shè)計(jì)和Gorilla的設(shè)計(jì)高度相似，所以Prometheus幾乎就是等于一個(gè)緩存TSDB。它本地存儲(chǔ)的特點(diǎn)決定了它不能用于long-term數(shù)據(jù)存儲(chǔ)，只能用于短期窗口的timeseries數(shù)據(jù)保存和查詢，并且不具有高可用性（宕機(jī)會(huì)導(dǎo)致歷史數(shù)據(jù)無(wú)法讀?。?。

內(nèi)存中的block數(shù)據(jù)未寫入磁盤時(shí)，block目錄下面主要保存wal文件:

./data/01BKGV7JBM69T2G1BGBGM6KB12
./data/01BKGV7JBM69T2G1BGBGM6KB12/meta.json
./data/01BKGV7JBM69T2G1BGBGM6KB12/wal/000002
./data/01BKGV7JBM69T2G1BGBGM6KB12/wal/000001

持久化的block目錄下wal文件被刪除，timeseries數(shù)據(jù)保存在chunk文件里。index用于索引timeseries在wal文件里的位置。

./data/01BKGV7JC0RY8A6MACW02A2PJD
./data/01BKGV7JC0RY8A6MACW02A2PJD/meta.json
./data/01BKGV7JC0RY8A6MACW02A2PJD/index
./data/01BKGV7JC0RY8A6MACW02A2PJD/chunks
./data/01BKGV7JC0RY8A6MACW02A2PJD/chunks/000001
./data/01BKGV7JC0RY8A6MACW02A2PJD/tombstones

對(duì)于本地存儲(chǔ)，prometheus提供了一些配置項(xiàng)，主要包括：

--storage.tsdb.path: 存儲(chǔ)數(shù)據(jù)的目錄，默認(rèn)為data/，如果要掛外部存儲(chǔ)，可以指定該目錄

--storage.tsdb.retention.time: 數(shù)據(jù)過期清理時(shí)間，默認(rèn)保存15天

--storage.tsdb.retention.size: 實(shí)驗(yàn)性質(zhì)，聲明數(shù)據(jù)塊的最大值，不包括wal文件，如512MB

--storage.tsdb.retention: 已被廢棄，改為使用storage.tsdb.retention.time

Prometheus將所有當(dāng)前使用的塊保留在內(nèi)存中。此外，它將最新使用的塊保留在內(nèi)存中，最大內(nèi)存可以通過storage.local.memory-chunks標(biāo)志配置。

監(jiān)測(cè)當(dāng)前使用的內(nèi)存量：

prometheus_local_storage_memory_chunks

process_resident_memory_bytes

監(jiān)測(cè)當(dāng)前使用的存儲(chǔ)指標(biāo)：

prometheus_local_storage_memory_series: 時(shí)間序列持有的內(nèi)存當(dāng)前塊數(shù)量

prometheus_local_storage_memory_chunks: 在內(nèi)存中持久塊的當(dāng)前數(shù)量

prometheus_local_storage_chunks_to_persist: 當(dāng)前仍然需要持久化到磁盤的的內(nèi)存塊數(shù)量

prometheus_local_storage_persistence_urgency_score: 緊急程度分?jǐn)?shù)

prometheus 2.0于2017-11-08發(fā)布，主要是存儲(chǔ)引擎進(jìn)行了優(yōu)化。

性能的整體提高：

與 Prometheus 1.8 相比，CPU使用率降低了 20％ - 40％

與 Prometheus 1.8 相比，磁盤空間使用率降低了 33％ - 50％

沒有太多查詢，平均負(fù)載的磁盤 I/O<1％

在Kubernetes集群這樣的動(dòng)態(tài)環(huán)境中，prometheus的數(shù)據(jù)平面通常看起來(lái)是這種樣式

垂直維度表示所有存儲(chǔ)的序列

水平維度表示樣本傳播的時(shí)間

如：

requests_total{path="/status", method="GET", instance="10.0.0.1:80"}
requests_total{path="/status", method="POST", instance="10.0.0.3:80"}
requests_total{path="/", method="GET", instance="10.0.0.2:80"}

Prometheus定期為所有系列收集新數(shù)據(jù)點(diǎn)，這意味著它必須在時(shí)間軸的右端執(zhí)行垂直寫入。但是，在查詢時(shí)，我們可能希望訪問平面上任意區(qū)域的矩形(各種label條件)

因此為了能夠在大量數(shù)據(jù)中有效地查找查詢序列，我們需要一個(gè)索引。

在Prometheus 1.x存儲(chǔ)層可以很好地處理垂直寫入模式，但是隨著規(guī)模增大，索引或出現(xiàn)一些問題，因此在2.0版本中重新設(shè)計(jì)了存儲(chǔ)引擎和索引，主要改造是：

樣本壓縮

現(xiàn)有存儲(chǔ)層的樣本壓縮功能在Prometheus的早期版本中發(fā)揮了重要作用。單個(gè)原始數(shù)據(jù)點(diǎn)占用16個(gè)字節(jié)的存儲(chǔ)空間。但當(dāng)普羅米修斯每秒收集數(shù)十萬(wàn)個(gè)數(shù)據(jù)點(diǎn)時(shí)，可以快速填滿硬盤。

但，同一系列中的樣本往往非常相似，我們可以利用這一類樣品（同樣label）進(jìn)行有效的壓縮。批量壓縮一系列的許多樣本的塊，在內(nèi)存中，將每個(gè)數(shù)據(jù)點(diǎn)壓縮到平均1.37字節(jié)的存儲(chǔ)。

這種壓縮方案運(yùn)行良好，也保留在新版本2存儲(chǔ)層的設(shè)計(jì)中。具體壓縮算法可以參考：Facebook的“Gorilla”論文中

時(shí)間分片

我們將新的存儲(chǔ)層劃分為塊（block），每個(gè)塊在一段時(shí)間內(nèi)保存所有序列。每個(gè)塊充當(dāng)獨(dú)立數(shù)據(jù)庫(kù)。

這樣每次查詢，僅檢查所請(qǐng)求的時(shí)間范圍內(nèi)的塊子集，查詢執(zhí)行時(shí)間自然會(huì)減少。

這種布局也使刪除舊數(shù)據(jù)變得非常容易(這在1.x的存儲(chǔ)設(shè)計(jì)中是一個(gè)很耗時(shí)的操作)。但在2.x中，一旦塊的時(shí)間范圍完全落后于配置的保留邊界，它就可以完全丟棄。

索引

一般prometheus的查詢是把metric+label做關(guān)鍵字的，而且是很寬泛，完全用戶自定義的字符，因此沒辦法使用常規(guī)的sql數(shù)據(jù)庫(kù)，prometheus的存儲(chǔ)層使用了全文檢索中的倒排索引概念，將每個(gè)時(shí)間序列視為一個(gè)小文檔。而metric和label對(duì)應(yīng)的是文檔中的單詞。

例如，requests_total{path="/status", method="GET", instance="10.0.0.1:80"}是包含以下單詞的文檔：

__name__="requests_total"

path="/status"

method="GET"

instance="10.0.0.1:80"

基準(zhǔn)測(cè)試

cpu、內(nèi)存、查詢效率都比1.x版本得到了大幅度的提升

具體測(cè)試結(jié)果參考：https://dzone.com/articles/pr...

如果您懷疑數(shù)據(jù)庫(kù)中的損壞引起的問題，則可以通過使用storage.local.dirtyflag配置，來(lái)啟動(dòng)服務(wù)器來(lái)強(qiáng)制執(zhí)行崩潰恢復(fù)。

如果沒有幫助，或者如果您只想刪除現(xiàn)有的數(shù)據(jù)庫(kù)，可以通過刪除存儲(chǔ)目錄的內(nèi)容輕松地啟動(dòng)：

1.停止服務(wù)：stop prometheus.

2.刪除數(shù)據(jù)目錄：rm -r /*

3.啟動(dòng)服務(wù)：start prometheus

Prometheus默認(rèn)是自己帶有存儲(chǔ)的，保存的時(shí)間為15天。但本地存儲(chǔ)也意味著Prometheus無(wú)法持久化數(shù)據(jù)，無(wú)法存儲(chǔ)大量歷史數(shù)據(jù)，同時(shí)也無(wú)法靈活擴(kuò)展。
為了保證Prometheus的簡(jiǎn)單性，Prometheus并沒有從自身集群的維度來(lái)解決這些問題，而是定義了兩種接口，remote_write/remote_read，將數(shù)據(jù)拋出去，你自己處理。

Prometheus的remote_storage 其實(shí)是一個(gè)adapter，至于在adapter的另一端是什么類型的時(shí)序數(shù)據(jù)庫(kù)它根本不關(guān)心，如果你愿意，你也可以編寫自己的adpater。

如：存儲(chǔ)的方式為：Prometheus —-發(fā)送數(shù)據(jù)—- > remote_storage_adapter —- 存儲(chǔ)數(shù)據(jù) —-> influxdb。

prometheus通過下面兩種方式來(lái)實(shí)現(xiàn)與其他的遠(yuǎn)端存儲(chǔ)系統(tǒng)對(duì)接：

Prometheus 按照標(biāo)準(zhǔn)的格式將metrics寫到遠(yuǎn)端存儲(chǔ)

Prometheus 按照標(biāo)準(zhǔn)格式從遠(yuǎn)端的url來(lái)讀取metrics

在遠(yuǎn)程讀的流程當(dāng)中，當(dāng)用戶發(fā)起查詢請(qǐng)求后，Promthues將向remote_read中配置的URL發(fā)起查詢請(qǐng)求(matchers,ranges)，Adaptor根據(jù)請(qǐng)求條件從第三方存儲(chǔ)服務(wù)中獲取響應(yīng)的數(shù)據(jù)。同時(shí)將數(shù)據(jù)轉(zhuǎn)換為Promthues的原始樣本數(shù)據(jù)返回給Prometheus Server。

當(dāng)獲取到樣本數(shù)據(jù)后，Promthues在本地使用PromQL對(duì)樣本數(shù)據(jù)進(jìn)行二次處理。

用戶可以在Promtheus配置文件中指定Remote Write(遠(yuǎn)程寫)的URL地址，一旦設(shè)置了該配置項(xiàng)，Prometheus將樣本數(shù)據(jù)通過HTTP的形式發(fā)送給適配器(Adaptor)。而用戶則可以在適配器中對(duì)接外部任意的服務(wù)。外部服務(wù)可以是真正的存儲(chǔ)系統(tǒng)，公有云的存儲(chǔ)服務(wù)，也可以是消息隊(duì)列等任意形式。

配置非常簡(jiǎn)單，只需要將對(duì)應(yīng)的地址配置下就行

remote_write:
  - url: "http://localhost:9201/write"

remote_read:
  - url: "http://localhost:9201/read"

現(xiàn)在社區(qū)已經(jīng)實(shí)現(xiàn)了以下的遠(yuǎn)程存儲(chǔ)方案

AppOptics: write

Chronix: write

Cortex: read and write

CrateDB: read and write

Elasticsearch: write

Gnocchi: write

Graphite: write

InfluxDB: read and write

OpenTSDB: write

PostgreSQL/TimescaleDB: read and write

SignalFx: write

可以使用讀寫完整的InfluxDB，我們使用了多prometheus server同時(shí)遠(yuǎn)程讀+寫，驗(yàn)證了速度還是可以的。并且InfluxDB生態(tài)完整，自帶了很多管理工具。

在一般情況下，Prometheus中存儲(chǔ)的每一個(gè)樣本大概占用1-2字節(jié)大小。如果需要對(duì)Prometheus Server的本地磁盤空間做容量規(guī)劃時(shí)，可以通過以下公式計(jì)算：

磁盤大小 = 保留時(shí)間 * 每秒獲取樣本數(shù) * 樣本大小

保留時(shí)間(retention_time_seconds)和樣本大小(bytes_per_sample)不變的情況下，如果想減少本地磁盤的容量需求，只能通過減少每秒獲取樣本數(shù)(ingested_samples_per_second)的方式。

因此有兩種手段，一是減少時(shí)間序列的數(shù)量，二是增加采集樣本的時(shí)間間隔。

考慮到Prometheus會(huì)對(duì)時(shí)間序列進(jìn)行壓縮，因此減少時(shí)間序列的數(shù)量效果更明顯。

遠(yuǎn)程讀寫解決了Promtheus的數(shù)據(jù)持久化問題。使其可以進(jìn)行彈性擴(kuò)展。另外還支持聯(lián)邦集群模式，用于解決橫向擴(kuò)展、網(wǎng)絡(luò)分區(qū)的問題（如地域A+B+C的監(jiān)控?cái)?shù)據(jù)，統(tǒng)一匯總到D），聯(lián)邦集群的配置將在后面的Promthues高可用文章中詳細(xì)說明。

附：kubecon2018上講Prometheus 2.0的帥哥

還有一本專門講Prometheus的書：Prometheus: Up & Running(600多頁(yè)...)

國(guó)內(nèi)沒找到賣的，找到了一本英文pdf的，還在翻譯理解中，有新的內(nèi)容會(huì)繼續(xù)同步在這個(gè)系列博客

。。。又找到一本：https://www.prometheusbook.com/

https://prometheus.io/docs/pr...

https://coreos.com/blog/prome...

https://dzone.com/articles/pr...

https://www.linuxidc.com/Linu...

http://ylzheng.com/2018/03/06...

https://www.cnblogs.com/vovli...

https://files-cdn.cnblogs.com...

https://www.bookstack.cn/read...

本文為容器監(jiān)控實(shí)踐系列文章，完整內(nèi)容見：container-monitor-book