Prometheus監控神器-Rules篇

• 2020 年 8 月 7 日
• 筆記
• Prometheus

本章主要對如何使用Prometheus與Alertmanager組件集成配置，以及對警報規則 Rules 的倆種類型及其模板內容進行講解。

與Alertmanager集成

Prometheus把產生的警報發給Alertmanager進行處理時，需要在Prometheus使用的配置文件中添加關聯Alertmanager的組件的對應配置資訊。

alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]
# alertmanagers 為 alertmanager_config 數組，

配置範例：

alerting:
  alert_relabel_configs: # 動態修改 alert 屬性的規則配置。
    - source_labels: [dc] 
      regex: (.+)\d+
      target_label: dc1
  alertmanagers:
    - static_configs:
        - targets: ['127.0.0.1:9093'] # 單實例配置
        #- targets: ['172.31.10.167:19093','172.31.10.167:29093','172.31.10.167:39093'] # 集群配置
  - job_name: 'Alertmanager'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
    static_configs:
    - targets: ['localhost:19093']

上面的配置中的 alert_relabel_configs是指警報重新標記在發送到Alertmanager之前應用於警報。 它具有與目標重新標記相同的配置格式和操作，外部標籤標記後應用警報重新標記，主要是針對集群配置。

這個設置的用途是確保具有不同外部label的HA對Prometheus服務端發送相同的警報資訊。

Alertmanager 可以通過 static_configs 參數靜態配置，也可以使用其中一種支援的服務發現機制動態發現，我們上面的配置是靜態的單實例，針對集群HA配置，後面會講。

此外，relabel_configs 允許從發現的實體中選擇 Alertmanager，並對使用的API路徑提供高級修改，該路徑通過 __alerts_path__ 標籤公開。

完成以上配置後，重啟Prometheus服務，用以載入生效，也可以使用前文說過的熱載入功能，使其配置生效。然後通過瀏覽器，訪問 //192.168.1.220:19090/alerts 就可以看 inactive pending firing 三個狀態，沒有警報資訊是因為我們還沒有配置警報規則 rules。

警報規則

警報規則 rules 使用的是 yaml 格式進行定義，在Prometheus中通過我們前面講過的 PromQL 配置實際警報觸發條件，Prometheus 會根據設置的警告規則 Ruels 以及配置間隔時間進行周期性計算，當滿足觸發條件規則會發送警報通知。
警報規則載入的是在 prometheus.yml 文件中進行配置，默認的警報規則進行周期運行計算的時間是1分鐘，可以使用 global 中的 evaluation_interval 來決定時間間隔。

範例：

global:
    evaluation_interval: 15s

警報規則可以指定多個文件，也可以自定到自定義的目錄下面，為了管理更為便捷，方便閱讀，可以把警報規則拆成多分，用以區分環境，系統，服務等，如：prod，test，dev 等等，並且支援以正則表達式定義。

範例：

rule_files:
    #- "/data/prometheus/rules/*.yml" # 正則表達式，會加在此目錄下所有警報規則配置文件
    - "/data/prometheus/rules/ops.yml" # 僅載入ops.yml警報規則文件
    #- "/data/prometheus/rules/prod-*.yml" 
    #- "/data/prometheus/rules/test-*.yml"
    #- "/data/prometheus/rules/dev-*.yml"

現在開始講告警規則 Rules 的定義，格式為YAML。

groups:
- name: <string>
  rules:
  - alert: <string>
    expr: <string>
    for:  [ <duration> | default 0 ]
    labels:
      [ <lable_name>: <label_value> ]
    annotations:
      [ <lable_name>: <tmpl_string> ]

groups:
- name: operations
  rules:
  - alert: node-down
    expr: up{env="operations"} != 1
    for: 5m
    labels:
      status: High
      team: operations
    annotations:
      description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} is Down ! ! !"
      value: '{{ $value }}'
      summary:  "The host node was down 20 minutes ago"

以上就是一個完整 Rules 的配置，如果Prometheus 在周期檢測中使用PromQ以env=operations為維度查詢，如果當前查詢結果中具有標籤operations，且返回值都不等於1的時候，發送警報。
對於寫好的 Rules 可以是常用 promtool 來check ruls.yml 的書寫格式是否正確。

/usr/local/bin/promtool check rules /data/prometheus/rules/ops.yml
Checking /data/prometheus/rules/ops.yml
  SUCCESS: 7 rules found

對於修改好的rules文件，保存以後，經過檢測沒有問題，直接重新熱載入 Prometheus就可以在頁面看到了。對於觸發警報規則，比較簡單了，直接修改運算值或者去停掉 node-exporter 服務，便可在介面看到警報資訊。一個告警在生命周期會有三種狀態

帶有for子句的警報觸發以後首先會先轉換成 Pending 狀態，然後在轉換為 Firing 狀態。這裡需要倆個周期才能觸發警報條件，如果沒有設置 for 子句，會直接 Inactive 狀態轉換成 Firing狀態，然後觸發警報，發送給 Receiver 設置的通知人。

在運行過程中，Prometheus會把Pending或Firing狀態的每一個告警創建一個 Alerts指標名稱，這個可以通過Rules來觸發警報測試，直接在UI中Graph查看指標 ALERTS，格式如下：

ALERTS{alertname="alert name",alertstate="pending|firing",<additional alert label>}

當警報處於激活狀態 Pending 或者 Firing時候，如上圖所示，樣本值為1。其他狀態為0。則不顯示。上圖已經觸發警報，其警報已經被轉發給Alertmanager組件，此時可以在瀏覽器上通過可以用過9093埠訪問，查看警報狀態。

現在我們來說一下整理下Prometheus從收集監控指標資訊到觸發警報的過程

Rules類型

Prometheus 支援兩種類型的 Rules ，可以對其進行配置，然後定期進行運算：recording rules 記錄規則 與 alerting rules 警報規則，規則文件的計算頻率與告警規則計算頻率一致，都是通過全局配置中的 evaluation_interval 定義。

alerting rules

要在Prometheus中使用Rules規則，就必須創建一個包含必要規則語句的文件，並讓Prometheus通過Prometheus配置中的rule_files欄位載入該文件，前面我們已經講過了。
其實語法都一樣，除了 recording rules 中的收集的指標名稱 record: <string> 欄位配置方式略有不同，其他都是一樣的。

配置範例：

- alert: ServiceDown
    expr: avg_over_time(up[5m]) * 100 < 50
    annotations:
      description: The service {{ $labels.job }} instance {{ $labels.instance }} is
        not responding for more than 50% of the time for 5 minutes.
      summary: The service {{ $labels.job }} is not responding
  - alert: RedisDown
    expr: avg_over_time(redis_up[5m]) * 100 < 50
    annotations:
      description: The Redis service {{ $labels.job }} instance {{ $labels.instance
        }} is not responding for more than 50% of the time for 5 minutes.
      summary: The Redis service {{ $labels.job }} is not responding
  - alert: PostgresDown
    expr: avg_over_time(pg_up[5m]) * 100 < 50
    annotations:
      description: The Postgres service {{ $labels.job }} instance {{ $labels.instance
        }} is not responding for more than 50% of the time for 5 minutes.
      summary: The Postgres service {{ $labels.job }} is not responding

recording rules

recording rules 是提前設置好一個比較花費大量時間運算或經常運算的表達式，其結果保存成一組新的時間序列數據。當需要查詢的時候直接會返回已經計算好的結果，這樣會比直接查詢快，同時也減輕了PromQl的計算壓力，同時對可視化查詢的時候也很有用，可視化展示每次只需要刷新重複查詢相同的表達式即可。

在配置的時候，除卻 record: <string> 需要注意，其他的基本上是一樣的，一個 groups 下可以包含多條規則 rules ，Recording 和 Rules 保存在 group 內，Group 中的規則以規則的配置時間間隔順序運算，也就是全局中的 evaluation_interval 設置。

配置範例：

groups:
- name: http_requests_total
  rules:
  - record: job:http_requests_total:rate10m
    expr: sum by (job)(rate(http_requests_total[10m]))
    lables:
      team: operations
  - record: job:http_requests_total:rate30m
    expr: sum by (job)(rate(http_requests_total[30m]))
    lables:
      team: operations             

上面的規則其實就是根據 record 規則中的定義，Prometheus 會在後台完成 expr 中定義的 PromQL 表達式周期性運算，以 job 為維度使用 sum 聚合運算符 計算 函數rate 對http_requests_total 指標區間 10m 內的增長率，並且將計算結果保存到新的時間序列 job:http_requests_total:rate10m 中，
同時還可以通過 labels 為樣本數據添加額外的自定義標籤，但是要注意的是這個 Lables 一定存在當前表達式 Metrics 中。

使用模板

模板是在警報中使用時間序列標籤和值展示的一種方法，可以用於警報規則中的注釋（annotation）與標籤（lable）。模板其實使用的go語言的標準模板語法，並公開一些包含時間序列標籤和值的變數。這樣查詢的時候，更具有可讀性，也可以執行其他PromQL查詢
來向警報添加額外內容，ALertmanager Web UI中會根據標籤值顯示器警報資訊。

{{ $lable.<lablename>}} 可以獲取當前警報實例中的指定標籤值

{{ $value }} 變數可以獲取當前PromQL表達式的計算樣本值。

groups:
- name: operations
  rules:
# monitor node memory usage
  - alert: node-memory-usage
    expr: (1 - (node_memory_MemAvailable_bytes{env="operations",job!='atlassian'} / (node_memory_MemTotal_bytes{env="operations"})))* 100 > 90
    for: 1m
    labels:
      status: Warning
      team: operations
    annotations:
      description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} memory usage above {{ $value }} ! ! !"
      summary:  "node os memory usage status"

調整好rules以後，我們可以使用 curl -XPOST //localhost:9090/-/reload 或者 對Prometheus服務重啟，讓警報規則生效。

這個時候，我們可以把閾值調整為 50 來進行故障模擬操作，這時在去訪問UI的時候，當持續1分鐘滿足警報條件，實際告警狀態已轉換為 Firing，可以在 Annotations中看到模板資訊 summary 與 description 已經成功顯示。

需要注意的是，一個穩定健壯的Prometheus監控系統中，要盡量使用模板化，這樣會降低性能開銷（Debug調試資訊等），同時也易於維護。

下面網站收錄了當前大部分的rules規則，大家可以對應自己的環境，配置相關服務的Rules。

[Prometheus告警規則收集(//awesome-prometheus-alerts.grep.to/)