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

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

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

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

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

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

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

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

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

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

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

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

內(nèi)存中的block數(shù)據(jù)未寫入磁盤時，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

對于本地存儲，prometheus提供了一些配置項，主要包括：

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

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

--storage.tsdb.retention.size: 實驗性質(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)測當(dāng)前使用的內(nèi)存量：

prometheus_local_storage_memory_chunks

process_resident_memory_bytes

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

prometheus_local_storage_memory_series: 時間序列持有的內(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ā)布，主要是存儲引擎進(jìn)行了優(yōu)化。

性能的整體提高：

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

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

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

在Kubernetes集群這樣的動態(tài)環(huán)境中，prometheus的數(shù)據(jù)平面通?？雌饋硎沁@種樣式

垂直維度表示所有存儲的序列

水平維度表示樣本傳播的時間

如：

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ù)點，這意味著它必須在時間軸的右端執(zhí)行垂直寫入。但是，在查詢時，我們可能希望訪問平面上任意區(qū)域的矩形(各種label條件)

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

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

樣本壓縮

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

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

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

時間分片

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

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

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

索引

一般prometheus的查詢是把metric+label做關(guān)鍵字的，而且是很寬泛，完全用戶自定義的字符，因此沒辦法使用常規(guī)的sql數(shù)據(jù)庫，prometheus的存儲層使用了全文檢索中的倒排索引概念，將每個時間序列視為一個小文檔。而metric和label對應(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)測試

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

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

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

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

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

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

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

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

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

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

prometheus通過下面兩種方式來實現(xiàn)與其他的遠(yuǎn)端存儲系統(tǒng)對接：

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

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

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

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

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

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

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

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

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

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同時遠(yuǎn)程讀+寫，驗證了速度還是可以的。并且InfluxDB生態(tài)完整，自帶了很多管理工具。

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

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

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

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

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

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

附：kubecon2018上講Prometheus 2.0的帥哥

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

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

。。。又找到一本：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)控實踐系列文章，完整內(nèi)容見：container-monitor-book