本章主要對如何使用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: dc1alertmanagers:- 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服務，用以加載生效，也可以使用前文說過的熱加載功能，使其配置生效。然后通過瀏覽器，訪問 http://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> ]

| 參數 | 描述 | | :-----: | :----: | |- name: <string>|警報規則組的名稱| |- alert: <string>|警報規則的名稱| |expr: <string|使用PromQL表達式完成的警報觸發條件，用于計算是否有滿足觸發條件| |<lable_name>: <label_value>|自定義標簽，允許自行定義標簽附加在警報上，比如high warning| |annotations: <lable_name>: <tmpl_string> |用來設置有關警報的一組描述信息，其中包括自定義的標簽，以及expr計算后的值。|

groups: - name: operationsrules:- alert: node-downexpr: up{env="operations"} != 1for: 5mlabels:status: Highteam: operationsannotations: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.ymlSUCCESS: 7 rules found

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

| 狀態 | 描述 | | :-----: | :----: | |Inactive|正常狀態，未激活警報| |Pending|已滿足觸發條件，但沒有滿足發送時間條件，此條件就是上面rules范例中的 for 5m 子句中定義的持續時間 | |Firing|滿足條件，且超過了 for 子句中的的指定持續時間5m|

帶有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從收集監控指標信息到觸發警報的過程

| 狀態 | 描述 | | :-----: | :----: | |1.定義規則|在Prometheus配置中，scrape_interval: 15s，默認是1分鐘，這個定義是收集監控指標信息的采集周期，同時配置對應的警報規則，可以是全局，也可以單獨為某一個metrics定義| |2.周期計算|對于表達式進行計算時，Prometheus中的配置中配置了 evaluation_interval: 15s，默認也是一分鐘，為警報規則的計算周期，evaluation_interval 只是全局計算周期值。| |3.1警報狀態轉換(pending)|當首次觸發警報規則條件成立，表達式為 true，并且沒有滿足警報規則中的for子句中的持續時間時，警報狀態切換為 Pending| |3.2警報狀態轉換(firing)|若下一個計算周期中，表達式仍為 true，并且滿足警報規則中的for子句的持續時間時，警報狀態轉換為 Firing，即為 active，警報會被Prometheus推送到ALertmanager組件| |3.3警報狀態轉換(period)|如果在 evaluation_interval 的計算周期內，表達式還是為 true，同時滿足 for子句的持續時間，持續轉發到Alertmanager，這里只是轉發狀態到Alertmanager，并不是直接發送通知到指定通知源| |3.4警報狀態轉換(resolve)|只到某個周期，表達式 為 false，警報狀態會變成 inactive ，并且會有一個 resolve被發送到Alertmanager，用于說明警報故障依解決，發送resolve信息需要自己單獨在Alertmanager中定義|

Rules類型

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

alerting rules

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

配置范例：

- alert: ServiceDownexpr: avg_over_time(up[5m]) * 100 < 50annotations:description: The service {{ $labels.job }} instance {{ $labels.instance }} isnot responding for more than 50% of the time for 5 minutes.summary: The service {{ $labels.job }} is not responding- alert: RedisDownexpr: avg_over_time(redis_up[5m]) * 100 < 50annotations: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: PostgresDownexpr: avg_over_time(pg_up[5m]) * 100 < 50annotations: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_totalrules:- record: job:http_requests_total:rate10mexpr: sum by (job)(rate(http_requests_total[10m]))lables:team: operations- record: job:http_requests_total:rate30mexpr: 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: operationsrules: # monitor node memory usage- alert: node-memory-usageexpr: (1 - (node_memory_MemAvailable_bytes{env="operations",job!='atlassian'} / (node_memory_MemTotal_bytes{env="operations"})))* 100 > 90for: 1mlabels:status: Warningteam: operationsannotations:description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} memory usage above {{ $value }} ! ! !"summary: "node os memory usage status"

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

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

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

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

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

總結

以上是生活随笔為你收集整理的prometheus 发送恢复 值_Prometheus监控神器-Rules篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。