Prometheus 到底 NB 在哪裏？- 天天5分鐘玩轉 Docker 容器技術（84）

本節討論 Prometheus 的核心，多維數據模型。咱們先來看一個例子。

好比要監控容器 webapp1 的內存使用狀況，最傳統和典型的方法是定義一個指標 container_memory_usage_bytes_webapp1 來記錄 webapp1 的內存使用數據。假如每1分鐘取一次樣，那麼在數據庫裏就會有相似下面的記錄。

好，如今需求發生了點變化，咱們須要知道全部 webapp 容器的內存使用狀況。若是仍是採用前面的方法，就不得不增長新的指標 container_memory_usage_bytes_webapp2、container_memory_usage_bytes_webapp3…

像 Graphite 這類更高級的監控方案採用了更爲優雅的層次化數據模型。爲了知足上面的需求，Graphite 會定義指標 container.memory_usage_bytes.webapp1、container.memory_usage_bytes.webapp2、container.memory_usage_bytes.webapp3…

而後就能夠用 container.memory_usage_bytes.webapp* 獲取全部的 webapp 的內存使用數據。

此外，Graphite 還支持 sum() 等函數對指標進行計算和處理，好比 sum(container.memory_usage_bytes.webapp*) 能夠獲得全部 webapp 容器佔用的總內存量。

目前爲止問題處理得都很好。但客戶老是會提出更多的需求：如今不只要按容器名字統計內存使用量，還要按鏡像來統計；或者想對比一下某一組容器在生產環境和測試環境中對內存使用的不一樣狀況。

固然你能夠說：只要定義更多的指標就能知足這些需求。好比 container.memory_usage_bytes.image1.webapp1、container.memory_usage_bytes.webapp1.prod等。

但問題在於咱們沒辦法提早預知客戶要用這些數據回答怎樣的問題，因此咱們沒辦法提早定義好全部的指標。

下面來看看 Prometheus 的解決方案。

Prometheus 只須要定義一個全局的指標 container_memory_usage_bytes，而後經過添加不一樣的維度數據來知足不一樣的業務需求。

好比對於前面 webapp1 的三條取樣數據，轉換成 Prometheus 多維數據將變成：

後面三列 container_name、image、env 就是數據的三個維度。想象一下，若是不一樣 env（prod、test、dev），不一樣 image（mycom/webapp:1.二、mycom/webapp:1.3）的容器，它們的內存使用數據中標註了這三個維度信息，那麼將能知足不少業務需求，好比：

1. 計算 webapp2 的平均內存使用狀況：avg(container_memory_usage_bytes{container_name=「webapp2」})

2. 計算運行 mycom/webapp:1.3 鏡像的全部容器內存使用總量：sum(container_memory_usage_bytes{image=「mycom/webapp:1.3」})

3. 統計不一樣運行環境中 webapp 容器內存使用總量：sum(container_memory_usage_bytes{container_name=~「webapp」}) by (env)

這裏只列了幾個例子，不過已經可以說明 Prometheus 數據模型的優點了：

1. 經過維度對數據進行說明，附加更多的業務信息，進而知足不一樣業務的需求。同時維度是能夠動態添加的，好比再給數據加上一個 user 維度，就能夠按用戶來統計容器內存使用量了。

2. Prometheus 豐富的查詢語言可以靈活、充分地挖掘數據的價值。前面示例中的 avg、sum、by 只是查詢語言中很小的一部分功能，已經爲咱們展示了 Prometheus 對多維數據進行分片、聚合的強大能力。

如今咱們已經知道 Prometheus 的強大之處了，再 NB 的東西也得落地，下一節就開始實踐。

書籍：
1.《天天5分鐘玩轉Docker容器技術》
https://item.jd.com/16936307278.html

2.《天天5分鐘玩轉OpenStack》
https://item.jd.com/12086376.html