Prometheus 入門

簡介

Prometheus 是一套開源的系統監控報警框架。它啓發於 Google 的 borgmon 監控系統，由工做在 SoundCloud 的 google 前員工在 2012 年建立，做爲社區開源項目進行開發，並於 2015 年正式發佈。

特色

做爲新一代的監控框架，Prometheus 具備如下特色：

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

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 生態圈中包含了多個組件，其中許多組件是可選的：

• 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 的主要模塊包括：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 根據配置文件，對接收到的警報進行處理，發出告警。 在圖形界面中，可視化採集數據。

相關概念

下面將對 Prometheus 中的數據模型（時間序列），metric 類型，instance 和 jobs等概念進行介紹。

數據模型

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"}。

Metrics種類

Prometheus客戶端庫提供了四種核心Metrics類型。

Counter（計數器）

• 說明：Counter是一個累積度量，它表示一個單調遞增的 Metrics，其值只能在重啓時遞增或重置爲零
• 場景：可使用Counter來表示http的請求數、已完成的任務數或錯誤數、下單數。

Gauge（測量儀）

• 說明：當前值的一次快照(snapshot)測量，可增可減。
• 場景：磁盤使用率，當前同時在線用戶數。

Histogram（直方圖）

• 說明：經過區間統計樣本分佈。
• 場景：請求延遲時間的統計。例如統計 0~200ms、200ms~400ms、400ms~800ms 區間的請求數有多。

Summary（彙總）

• 說明：根據樣本統計出百分位。
• 場景：請求延遲時間的統計。例如統計 95%的請求延遲 < xxx ms ，99%的請求延遲 < xxx ms

instance 和 jobs

在Prometheus術語中，你能夠scrape（刮擦）的端點稱爲 實例，一般對應於單個進程。一組同種類型的 instances（主要用於保證可擴展性和可靠性），例如：具備四個複製instances（實例）的API服務器job做業:

• 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

當Prometheus scrape（刮擦）目標時，它會自動在scrape的時間序列上附加一些標籤，用來識別scrape的目標。

• job：目標所屬的已配置job名稱。
• instance：:已刮擦的目標URL 的一部分。

對於每次實例 scrape（刮取，Prometheus都會在如下時間序列中存儲樣本：

• up{job="<job-name>", instance="<instance-id>"}：1若是實例是健康的，便可達，或者0刮擦失敗。
• scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}：刮擦持續時間。
• scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}：應用度量標準從新標記後剩餘的樣本數。
• scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}：目標暴露的樣本數。
• scrape_series_added{job="<job-name>", instance="<instance-id>"}：該刮擦中新系列的大體數量。v2.10中的新功能。

up時間序列對於實例可用性監視很是有用。

安裝和配置

安裝

你能夠在官網 prometheus.io/download/ 下載 安裝包，解壓後使用。爲了方便，我使用docker 鏡像的方式 運行Prometheus。

docker run --name prometheus -d -p 9090:9090 prom/prometheus
複製代碼

瀏覽器輸入http://localhost:9090 ，訪問 Prometheus 的 Web UI：

點擊菜單欄 「Status」 下的 Targets ，界面以下：

能夠看大Prometheus 自身 metrics 處於UP狀態 ，說明 安裝成功。

配置

Prometheus 的配置文件 prometheus.yml 內容以下：

# 全局設置，能夠被覆蓋
global:
  scrape_interval:     15s
  evaluation_interval: 15s
  
rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: prometheus
    static_configs:
    - targets: ['localhost:9090']
複製代碼

該global塊控制 Prometheus 的全局配置。咱們有兩種選擇。第一個，scrape_interval控制Prometheus 刮擦目標的頻率。你能夠爲單個目標覆蓋此值。在這種狀況下，全局設置是每15秒刮一次。該evaluation_interval選項控制普羅米修斯評估規則的頻率。Prometheus 使用規則建立新的時間序列並生成警報。

該rule_files塊指定咱們但願 Prometheus 加載的任何規則的位置。如今咱們沒有規則。

最後一個塊scrape_configs控制 Prometheus 監視的資源。因爲 Prometheus 還將本身的數據公開爲HTTP端點，所以它能夠抓取並監控自身的健康情況。在默認配置中有一個名爲 prometheus 的job，它抓取 prometheus 服務器 公開的時間序列數據。該做業包含一個靜態配置的目標，即端口9090上的本地主機。返回的時間序列數據將詳細說明Prometheus服務器的狀態和性能。

實驗

Prometheus HTTP 度量模擬器

爲了演示 Prometheus 的簡單使用，這裏運行一個 Prometheus HTTP 度量模擬器。模擬一個簡單的HTTP微服務，生成Prometheus Metrics，經過 docker 運行。

docker run -p 8080:8080 pierrevincent/prom-http-simulator:0.1
複製代碼

它在/metrics端點下公開如下Prometheus指標：

• http_requests_total：請求計數器，標籤endpoint和status
• http_request_duration_milliseconds：請求延遲直方圖

能夠開啓流量高峯模式，更改流量高峯模式能夠經過如下方式完成：

# ON
curl -X POST http://127.0.0.1:8080/spike/on
 # OFF
curl -X POST http://127.0.0.1:8080/spike/off
 # RANDOM
curl -X POST http://127.0.0.1:8080/spike/random
複製代碼

錯誤率默認爲1％。它能夠更改成0到100之間的數字：

# 例如將錯誤率設置爲50%
curl -H 'Content-Type: application/json' -X PUT -d '{"error_rate": 50}' http://127.0.0.1:8080/error_rate
複製代碼

修改Prometheus配置

須要將 HTTP 度量模擬器 的 metrics端點 配置到 Prometheus的配置文件 prometheus.yml 中。

建立一個 prometheus.yml 文件 內容以下：

global:
  scrape_interval: 5s
  evaluation_interval: 5s
  scrape_timeout: 5s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']
  - job_name: 'http-simulator'
    metrics_path: /metrics
    static_configs:
    - targets: ['172.16.1.232:8080']
複製代碼

經過docker up 命令替換 容器中的配置文件：

docker cp prometheus.yml prometheus:/etc/prometheus/
複製代碼

重啓容器：

docker restart prometheus
複製代碼

訪問 http://localhost:9090/targets ，發現已經出現了 target 「http-simulator」 ，而且爲UP狀態。

查詢

請求率(Request Rate)查詢

查詢http請求數

http_requests_total{job="http-simulator"}
複製代碼

查詢成功login請求數

http_requests_total{job="http-simulator", status="200", endpoint="/login"}
複製代碼

查詢成功請求數，以endpoint區分

http_requests_total{job="http-simulator", status="200"}
複製代碼

查詢總成功請求數

sum(http_requests_total{job="http-simulator", status="200"})
複製代碼

查詢成功請求率，以endpoint區分

rate(http_requests_total{job="http-simulator", status="200"}[5m])
複製代碼

查詢總成功請求率

sum(rate(http_requests_total{job="http-simulator", status="200"}[5m]))
複製代碼

延遲分佈(Latency distribution)查詢

查詢http-simulator延遲分佈

http_request_duration_milliseconds_bucket{job="http-simulator"}
複製代碼

查詢成功login延遲分佈

http_request_duration_milliseconds_bucket{job="http-simulator", status="200", endpoint="/login"}
複製代碼

不超過200ms延遲的成功login請求佔比

sum(http_request_duration_milliseconds_bucket{job="http-simulator", status="200", endpoint="/login", le="200"}) / sum(http_request_duration_milliseconds_count{job="http-simulator", status="200", endpoint="/login"})
複製代碼

成功login請求延遲的99百分位

histogram_quantile(0.99, rate(http_request_duration_milliseconds_bucket{job="http-simulator", status="200", endpoint="/login"}[5m]))
複製代碼

上面給出的這些查詢表達式，在 prometheus 的 查詢界面上自行測試下 ，這裏就不一一測試了，

總結

本篇對 Prometheus 的組成，架構和基本概念進行了介紹，並實例演示了 Prometheus 的查詢表達式的應用。本篇是 Prometheus 系列的第一篇， 後續還會有Prometheus與其餘圖形界面的集成，與 springboot 應用的集成等 。

參考

prometheus.io/docs/introd… www.ibm.com/developerwo…

關注我