（六）Prometheus 架構
Prometheus 是一個非常優秀的監控工具，準確的說，應該是監控方案，Prometheus 提供了監控資料搜集、存盤、處理、可視化和告警一套完整的解決方案，
（1）架構
Prometheus 架構如下：
官網上的原始架構圖比上面這張要復雜一些，為了集中大家的注意力，我只保留了最重要的組件，
-
Prometheus Server
Prometheus Server 負責從 Exporter 拉取和存盤監控資料，并提供一套靈活的查詢語言（PromQL）供用戶使用，
-
Exporter
Exporter 負責收集目標物件（host, container…）的性能資料，并通過 HTTP 介面供 Prometheus Server 獲取，
-
可視化組件
監控資料的可視化展現對于監控方案至關重要，以前 Prometheus 自己開發了一套工具，不過后來廢棄了，因為開源社區出現了更為優秀的產品 Grafana，Grafana 能夠與 Prometheus 無縫集成，提供完美的資料展示能力，
-
Alertmanager
用戶可以定義基于監控資料的告警規則，規則會觸發告警，一旦 Alermanager 收到告警，會通過預定義的方式發出告警通知，支持的方式包括 Email、PagerDuty、Webhook 等，
也許一些熟悉其他監控方案的同學看了 Prometheus 的架構會不以為然，“這些功能 Zabbix、Graphite、Nagios 這類監控系統也都有，沒什么特別的啊！”，
Prometheus 最大的亮點和先進性是它的多維資料模型，下節我們重點介紹，
（七）Prometheus 的優勢
本節討論 Prometheus 的核心，多維資料模型，我們先來看一個例子，
比如要監控容器 webapp1 的記憶體使用情況，最傳統和典型的方法是定義一個指標 container_memory_usage_bytes_webapp1 來記錄 webapp1 的記憶體使用資料，假如每1分鐘取一次樣，那么在資料庫里就會有類似下面的記錄，
| time | container_memory_usage_bytes_webapp1 |
|---|---|
| 00:01:00 | 37738736 |
| 00:02:00 | 37736822 |
| 00:03:00 | 37723425 |
| ，，， | ，，， |
? 好，現在需求發生了點變化，我們需要知道所有 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 多維資料將變成：
| time | container_memory_usage_bytes_webapp1 |
container_name | image | env |
|---|---|---|---|---|
| 00:01:00 | 37738736 | webapp1 | mycom/webapp:1.2 | prod |
| 00:02:00 | 37736822 | webapp1 | mycom/webapp:1.2 | prod |
| 00:03:00 | 37723425 | webapp1 | mycom/webapp:1.2 | prod |
| ... | ... |
后面三列 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 對多維資料進行分片、聚合的強大能力，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/243169.html
標籤：其他