監控神器-Prometheus(原理和實踐)

特點

Prometheus 具有以下特點：

• 強大的多維度數據模型：

1. 1. 時間序列數據通過 metric 名和鍵值對來區分。
   2. 所有的 metrics 都可以設置任意的多維標籤。
   3. 數據模型更隨意，不需要刻意設置爲以點分隔的字符串。
   4. 可以對數據模型進行聚合，切割和切片操作。
   5. 支持雙精度浮點類型，標籤可以設爲全 unicode。

• 靈活而強大的查詢語句（PromQL）：在同一個查詢語句，可以對多個 metrics 進行乘法、加法、連接、取分數位等操作。
• 易於管理： Prometheus server 是一個單獨的二進制文件，可直接在本地工作，不依賴於分佈式存儲。
• 高效：平均每個採樣點僅佔 3.5 bytes，且一個 Prometheus server 可以處理數百萬的 metrics。
• 使用 pull 模式採集時間序列數據，這樣不僅有利於本機測試而且可以避免有問題的服務器推送壞的 metrics。
• 可以採用 push gateway 的方式把時間序列數據推送至 Prometheus server 端。
• 可以通過服務發現或者靜態配置去獲取監控的 targets。
• 有多種可視化圖形界面。
• 易於伸縮。

由於數據採集可能會有丟失，所以 Prometheus 不適用對採集數據要 100% 準確的情形。但如果用於記錄時間序列數據，Prometheus 具有很大的查詢優勢，此外，Prometheus 適用於微服務的體系架構。

 

Prometheus 組成及架構

Prometheus 生態圈中包含了多個組件，其中很多組件是可選的：

• Prometheus Server: 用於收集和存儲時間序列數據。
• Client Library: 客戶端庫，爲需要監控的服務生成相應的 metrics 並暴露給 Prometheus server。當 Prometheus server 來 pull 時，直接返回實時狀態的 metrics。
• Push Gateway: 主要用於短期的 jobs。由於這類 jobs 存在時間較短，可能在 Prometheus 來 pull 之前就消失了。爲此，這次 jobs 可以直接向 Prometheus server 端推送它們的 metrics。這種方式主要用於服務層面的 metrics，對於機器層面的 metrices，需要使用 node exporter。
• Exporters: 用於暴露已有的第三方服務的 metrics 給 Prometheus。
• Alertmanager: 從 Prometheus server 端接收到 alerts 後，會進行去除重複數據，分組，並路由到對收的接受方式，發出報警。常見的接收方式有：電子郵件，pagerduty，OpsGenie, webhook 等。
• 各種支持工具。

架構圖

從上圖可以看出，Prometheus 的主要模塊包括：Prometheus server, exporters, Pushgateway, PromQL, Alertmanager 以及圖形界面。

工作流程

大概的工作流程如下：

1. Prometheus server 定期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來自 Pushgateway 發過來的 metrics，或者從其他的 Prometheus server 中拉 metrics。
2. Prometheus server 在本地存儲收集到的 metrics，並運行已定義好的 alert.rules，記錄新的時間序列或者向 Alertmanager 推送警報。
3. Alertmanager 根據配置文件，對接收到的警報進行處理，發出告警。
4. 在圖形界面中，可視化採集數據。

 

Prometheus相關概念

數據模型

Prometheus 中存儲的數據爲時間序列，是由 metric 的名字和一系列的標籤（鍵值對）組成唯一標識，不同的標籤則代表不同的時間序列。

• metric 名字：該名字應該具有語義，一般用於表示 metric 的功能，例如：http_requests_total, 表示 http 請求的總數。其中，metric 名字由 ASCII 字符，數字，下劃線，以及冒號組成，且必須滿足正則表達式 [a-zA-Z_:][a-zA-Z0-9_:]*。
• 標籤：使同一個時間序列有了不同維度的識別。例如 http_requests_total{method=“Get”} 表示所有 http 請求中的 Get 請求。當 method=“post” 時，則爲新的一個 metric。標籤中的鍵由 ASCII 字符，數字，以及下劃線組成，且必須滿足正則表達式 [a-zA-Z_:][a-zA-Z0-9_:]*。
• 樣本：實際的時間序列，每個序列包括一個 float64 的值和一個毫秒級的時間戳。
• 格式：{=, …}，例如：http_requests_total{method=“POST”,endpoint="/api/tracks"}。

Metric類型

Prometheus 客戶端庫主要提供四種主要的 metric 類型：

Counter

• 一種累加的 metric，典型的應用如：請求的個數，結束的任務數， 出現的錯誤數等等。

例如，查詢 http_requests_total{method=“get”, job=“Prometheus”, handler=“query”} 返回 8，10 秒後，再次查詢，則返回 14。

Gauge

• 一種常規的 metric，典型的應用如：溫度，運行的 goroutines 的個數。
• 可以任意加減。

例如：go_goroutines{instance=“172.17.0.2”, job=“Prometheus”} 返回值 147，10 秒後返回 124。

Histogram

• 可以理解爲柱狀圖，典型的應用如：請求持續時間，響應大小。
• 可以對觀察結果採樣，分組及統計。

例如：

Summary

• 類似於 Histogram, 典型的應用如：請求持續時間，響應大小。
• 提供觀測值的 count 和 sum 功能。
• 提供百分位的功能，即可以按百分比劃分跟蹤結果。

JOBS AND INSTANCES

用Prometheus術語來說，可以抓取的端點稱爲instance，通常對應於單個進程。具有相同目的的instances 的集合（例如，出於可伸縮性或可靠性而複製的過程）稱爲job。

例如，一個具有四個複製實例的API服務器作業:

• job: api-server

• • instance 1: 1.2.3.4:5670
  • instance 2: 1.2.3.4:5671
  • instance 3: 5.6.7.8:5670
  • instance 4: 5.6.7.8:5671

instance: 一個單獨 scrape 的目標， 一般對應於一個進程。<host>:<port>

jobs: 一組同種類型的 instances（主要用於保證可擴展性和可靠性）

 

Node exporter

Node exporter 主要用於暴露 metrics 給 Prometheus，其中 metrics 包括：cpu 的負載，內存的使用情況，網絡等。

 

Pushgateway

Pushgateway 是 Prometheus 生態中一個重要工具，使用它的原因主要是：

• Prometheus 採用 pull 模式，可能由於不在一個子網或者防火牆原因，導致Prometheus 無法直接拉取各個 target數據。
• 在監控業務數據的時候，需要將不同數據彙總, 由 Prometheus 統一收集。

由於以上原因，不得不使用 pushgateway，但在使用之前，有必要了解一下它的一些弊端：

• 將多個節點數據彙總到 pushgateway, 如果 pushgateway 掛了，受影響比多個 target 大。
• Prometheus 拉取狀態 up 只針對 pushgateway, 無法做到對每個節點有效。
• Pushgateway 可以持久化推送給它的所有監控數據。因此，即使你的監控已經下線，prometheus 還會拉取到舊的監控數據，需要手動清理 pushgateway 不要的數據。

爲了防止 pushgateway 重啓或意外掛掉，導致數據丟失，我們可以通過 -persistence.file 和 -persistence.interval 參數將數據持久化下來。

 

安裝實踐

Prometheus(服務端搭建):https://blog.csdn.net/qq_37598011/article/details/101105086

Pushgateway/Alertmanager/export:待續

 

文檔

https://prometheus.io/docs/introduction/overview/