共計 1828 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關如何理解 Prometheus 的多維數據模型，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

我們討論  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.2、mycom/webapp:1.3）的容器，它們的內存使用數據中標注了這三個維度信息，那么將能滿足很多業務需求，比如：

計算 webapp2 的平均內存使用情況：avg(container_memory_usage_bytes{container_name=“webapp2”})

計算運行 mycom/webapp:1.3 鏡像的所有容器內存使用總量：sum(container_memory_usage_bytes{image=“mycom/webapp:1.3”})

統計不同運行環境中 webapp 容器內存使用總量：sum(container_memory_usage_bytes{container_name=~“webapp”}) by (env)

這里只列了幾個例子，不過已經能夠說明 Prometheus 數據模型的優勢了：

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

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

關于如何理解 Prometheus 的多維數據模型就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。