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

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

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

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

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

以下所有內容均基于prometheus2.7版本

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

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

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

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

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

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

內存中的block數據未寫入磁盤時，block目錄下面主要保存wal文件:

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

持久化的block目錄下wal文件被刪除，timeseries數據保存在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: 存儲數據的目錄，默認為data/，如果要掛外部存儲，可以指定該目錄

--storage.tsdb.retention.time: 數據過期清理時間，默認保存15天

--storage.tsdb.retention.size: 實驗性質，聲明數據塊的最大值，不包括wal文件，如512MB

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

Prometheus將所有當前使用的塊保留在內存中。此外，它將最新使用的塊保留在內存中，最大內存可以通過storage.local.memory-chunks標志配置。

監(jiān)測當前使用的內存量：

prometheus_local_storage_memory_chunks

process_resident_memory_bytes

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

prometheus_local_storage_memory_series: 時間序列持有的內存當前塊數量

prometheus_local_storage_memory_chunks: 在內存中持久塊的當前數量

prometheus_local_storage_chunks_to_persist: 當前仍然需要持久化到磁盤的的內存塊數量

prometheus_local_storage_persistence_urgency_score: 緊急程度分數

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

性能的整體提高：

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

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

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

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

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

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

如：

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

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

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

樣本壓縮

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

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

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

時間分片

我們將新的存儲層劃分為塊（block），每個塊在一段時間內保存所有序列。每個塊充當獨立數據庫。

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

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

索引

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

例如，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"

基準測試

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

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

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

如果沒有幫助，或者如果您只想刪除現有的數據庫，可以通過刪除存儲目錄的內容輕松地啟動：

1.停止服務：stop prometheus.

2.刪除數據目錄：rm -r /*

3.啟動服務：start prometheus

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

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

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

prometheus通過下面兩種方式來實現與其他的遠端存儲系統對接：

Prometheus 按照標準的格式將metrics寫到遠端存儲

Prometheus 按照標準格式從遠端的url來讀取metrics

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

當獲取到樣本數據后，Promthues在本地使用PromQL對樣本數據進行二次處理。

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

配置非常簡單，只需要將對應的地址配置下就行

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

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

現在社區(qū)已經實現了以下的遠程存儲方案

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

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

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

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

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

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

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

附：kubecon2018上講Prometheus 2.0的帥哥

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

國內沒找到賣的，找到了一本英文pdf的，還在翻譯理解中，有新的內容會繼續(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)控實踐系列文章，完整內容見：container-monitor-book