眾所周知，Prometheus從CNCF畢業(yè)后，已經(jīng)成為運維磚工喜愛的系統(tǒng)監(jiān)控框架。
由于本公司的磚工之前都沒有用過Prometheus，使用的是比Prometheus更挫的Falcon拨黔。在大范圍使用Prometheus之前，需要對Prometheus的基本性能簡單測試绰沥，獲得一些數(shù)據(jù)用于估算Scalability和Capacity篱蝇。
(本文所述，"磚"即"監(jiān)控數(shù)據(jù)"徽曲；“工人”即"Prometheus"零截；"路"即"網(wǎng)絡(luò)信道")
Prometheus的角色分配如下:
- 搬磚工人: Prometheus
- 磚廠: 任意程序 (業(yè)務(wù)程序、Kubelet秃臣、ElasticSearch...)
- 磚: 各個程序提供的涧衙、符合Prometheus格式的數(shù)據(jù)接口
- 倉庫: 時間序列數(shù)據(jù)庫 (PromuTSDB、OpenTSDB奥此、InfluxDB...)
- 監(jiān)工: 管理搬磚工人的工具
- 消費者: 讀數(shù)據(jù)的 (Grafana弧哎、Kabana...)
Prometheus是標準的數(shù)據(jù)搬運系統(tǒng)。數(shù)據(jù)搬運系統(tǒng)即字面的意思稚虎，Prometheus不產(chǎn)生數(shù)據(jù)撤嫩，只從系統(tǒng)各處搬運數(shù)據(jù)到數(shù)據(jù)庫。
我們先看一下"磚"是什么樣子的蠢终。
(以下指標數(shù)據(jù)都是由業(yè)務(wù)程序提供的)
下面是一個Prometheus指標的例子：
container_cpu_usage_seconds_total{container_name="abc",cpu="total",id="123",name="def"} 4751.708280444
以上述指標為例序攘，Promethues指標由如下基本部分組成：
- 指標名字 - metric name - container_cpu_usage_seconds_total
- 值 - sampling value(float64) - 4751.708280444
- 標簽 - label name, value - container_name="abc"...
- 時間戳 - timestamp (Prometheus維護)
也可以定義一個“指標的集合”茴她，如下所示
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
...
以下部分組成“指標的集合”:
- 說明 - HELP <name> <descriptions> - go_gc_duration_seconds ...
- 集合名字 - TYPE <name> <type> - go_gc_duration_seconds summary <summary>
具體細節(jié)詳見官方文檔-教你寫Client、官方文檔-數(shù)據(jù)模型程奠、官方文檔-指標類型丈牢、官方文檔-推薦指標輸出格式。另外梦染，可以參考這個博客開始簡單的例子赡麦。
總之朴皆，每個程序按照格式帕识，以Web服務(wù)的形式暴露自己的指標，Prometheus就可以抓取啦遂铡。
Prometheus的基本結(jié)構(gòu)
Prometheus運行的基本結(jié)構(gòu)如下圖1所示肮疗。
- 指標數(shù)據(jù)在業(yè)務(wù)提供的服務(wù)上以Web服務(wù)的形式暴露出來，由配置文件和服務(wù)發(fā)現(xiàn)機制通知Prometheus去指定位置抓取數(shù)據(jù)扒接。
- Prometheus抓取指標后伪货，搬運到本地(PromuTSDB)、遠程倉庫(OpenTSDB钾怔、InfluxDB...)
- 其他消費者碱呼，包括Grafana、Prometheus的自身的Web服務(wù)宗侦，從時間序列數(shù)據(jù)庫中取數(shù)據(jù)
所以愚臀，實際上Prometheus真正的架構(gòu)應(yīng)該是這樣子的。
作為一個搬磚工人矾利，Prometheus需要知道如下信息姑裂。
- 磚在哪? - 配置文件、服務(wù)發(fā)現(xiàn)組件提供地址
- 怎么搬? - Prometheus Query配置
- 搬哪去? - 數(shù)據(jù)存儲配置
磚在哪?
根據(jù)配置文件和服務(wù)發(fā)現(xiàn)組件男旗，Prometheus會生成一些Target舶斧。Prometheus會定期訪問這些Target。
怎么搬?
如果單個Prometheus不能支持足夠大的數(shù)據(jù)搬運量察皇，可以開發(fā)簡單的管理程序茴厉，進行
target對應(yīng)的配置文件分片，則很容易橫向拓展什荣。
在2.0版本之前矾缓，除了搬運文本數(shù)據(jù)外，還支持搬運Protobuf類型的數(shù)據(jù)（現(xiàn)不支持）
獲取訪問Target的HTTP Body溃睹，并在解析之后而账，存儲到數(shù)據(jù)庫中。
搬哪去?
Prometheus默認提供了PromuTSDB因篇，數(shù)據(jù)以壓縮文件的形式存儲在本地泞辐。但在Prometheus抓取目標增多時笔横，本地磁盤顯然是存不下這么多數(shù)據(jù)的，因此Prometheus提供了Remote Storage接口咐吼。
根據(jù)Remote Storage接口吹缔，用戶可以使用自己維護的后端存儲，如OpenTSDB锯茄、InfluxDB厢塘、PostgreSQL，存儲指標數(shù)據(jù)肌幽。在使用過程中晚碾，用戶需要自己實現(xiàn)一個Remote Storage Adapter。
這個Adapter提供轉(zhuǎn)發(fā)功能喂急，包括Remote Read和Remote Write格嘁。(允許只實現(xiàn)一種)
- Remote Write: Prometheus發(fā)送規(guī)定格式的數(shù)據(jù)給Adapter，Adapter轉(zhuǎn)義后發(fā)送給數(shù)據(jù)庫廊移。
- Remote Read: Prometheus規(guī)定Adapter需要解析四種運算符 "=","!=","=~","!~"糕簿。 用戶在界面上查詢時，Prometheus發(fā)送查詢命令給Adapter狡孔，Adapter轉(zhuǎn)義后發(fā)送給數(shù)據(jù)庫懂诗。
為了保證充分評估Prometheus的性能，我們可以按照這個圖2思路苗膝，逐個對每條路徑殃恒、組件開展性能實驗，估算出系統(tǒng)的性能瓶頸荚醒。
在接下來的文章里芋类，我們會提供詳細的Prometheus性能實驗報告及代碼，討論如下問題
- 每個工人能搬多少磚? - 單個Prometheus容量
- 工人取一塊磚平均要多久界阁？ - 取數(shù)據(jù)延遲
- 工人送一塊磚到倉庫要多久? - 存數(shù)據(jù)網(wǎng)絡(luò)延遲
- 倉庫能放多少磚? - 數(shù)據(jù)庫容量
- 工人搬磚的時候侯繁，會不會把路占了，讓別人走不了泡躯？- 占用網(wǎng)絡(luò)帶寬
敬請期待贮竟。
