Prometheus學習筆記三–郵件報警規則配置

如鯨向海，似鳥投林

1.Prometheus郵件報警
Prometheus的架構中被劃分爲兩個部分，在Prometheus Server中定義告警規則以及產生告警，Alertmanager組件則用於處理這些由Prometheus產生的告警。Alertmanager即Prometheus體系中告警的統一處理中心。Alertmanager提供了多種內置第三方告警通知方式，同時還提供了對Webhook通知的支持，通過Webhook用戶可以完成對告警更多個性化的擴展。

Prometheus報警簡介
告警能力在Prometheus的架構中被劃分成兩個獨立的部分。如下所示，通過在Prometheus中定義AlertRule（告警規則），Prometheus會週期性的對告警規則進行計算，如果滿足告警觸發條件就會向Alertmanager發送告警信息。

在Prometheus中一條告警規則主要由以下幾部分組成：

1. 告警名稱：用戶需要爲告警規則命名，當然對於命名而言，需要能夠直接表達出該告警的主要內容
2. 告警規則：告警規則實際上主要由PromQL進行定義，其實際意義是當表達式（PromQL）查詢結果持續多長時間（During）後出發告警

在Prometheus中，還可以通過Group（告警組）對一組相關的告警進行統一定義。當然這些定義都是通過YAML文件來統一管理的。

Alertmanager作爲一個獨立的組件，負責接收並處理來自Prometheus Server(也可以是其它的客戶端程序)的告警信息。Alertmanager可以對這些告警信息進行進一步的處理，比如當接收到大量重複告警時能夠消除重複的告警信息，同時對告警信息進行分組並且路由到正確的通知方，Prometheus內置了對郵件，Slack等多種通知方式的支持，同時還支持與Webhook的集成，以支持更多定製化的場景。例如，目前Alertmanager還不支持釘釘，那用戶完全可以通過Webhook與釘釘機器人進行集成，從而通過釘釘接收告警信息。同時AlertManager還提供了靜默和告警抑制機制來對告警通知行爲進行優化。

Alertmanager的特性
Alertmanager除了提供基本的告警通知能力以外，還主要提供瞭如：分組、抑制以及靜默等告警特性：

分組
**分組機制可以將詳細的告警信息合併成一個通知。**在某些情況下，比如由於系統宕機導致大量的告警被同時觸發，在這種情況下分組機制可以將這些被觸發的告警合併爲一個告警通知，避免一次性接受大量的告警通知，而無法對問題進行快速定位。
例如，當集羣中有數百個正在運行的服務實例，並且爲每一個實例設置了告警規則。假如此時發生了網絡故障，可能導致大量的服務實例無法連接到數據庫，結果就會有數百個告警被髮送到Alertmanager。
而作爲用戶，可能只希望能夠在一個通知中就能查看哪些服務實例受到影響。這時可以按照服務所在集羣或者告警名稱對告警進行分組，而將這些告警內聚在一起成爲一個通知。
告警分組，告警時間，以及告警的接受方式可以通過Alertmanager的配置文件進行配置。
抑制
抑制是指當某一告警發出後，可以停止重複發送由此告警引發的其它告警的機制。
例如，當集羣不可訪問時觸發了一次告警，通過配置Alertmanager可以忽略與該集羣有關的其它所有告警。這樣可以避免接收到大量與實際問題無關的告警通知。
抑制機制同樣通過Alertmanager的配置文件進行設置。
靜默
靜默提供了一個簡單的機制可以快速根據標籤對告警進行靜默處理。如果接收到的告警符合靜默的配置，Alertmanager則不會發送告警通知。
靜默設置需要在Alertmanager的Werb頁面上進行設置。

2.自定義Prometheus告警規則
Prometheus中的告警規則允許你基於PromQL表達式定義告警觸發條件，Prometheus後端對這些觸發規則進行週期性計算，當滿足觸發條件後則會觸發告警通知。默認情況下，用戶可以通過Prometheus的Web界面查看這些告警規則以及告警的觸發狀態。當Promthues與Alertmanager關聯之後，可以將告警發送到外部服務如Alertmanager中並通過Alertmanager可以對這些告警進行進一步的處理。

定義告警規則
一條典型的告警規則如下所示：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency
      description: description info

在告警規則文件中，我們可以將一組相關的規則設置定義在一個group下。在每一個group中我們可以定義多個告警規則(rule)。一條告警規則主要由以下幾部分組成：

alert：告警規則的名稱。 expr：基於PromQL表達式告警觸發條件，用於計算是否有時間序列滿足該條件。
for：評估等待時間，可選參數。用於表示只有當觸發條件持續一段時間後才發送告警。在等待期間新產生告警的狀態爲pending。
labels：自定義標籤，允許用戶指定要附加到告警上的一組附加標籤。
annotations：用於指定一組附加信息，比如用於描述告警詳細信息的文字等，annotations的內容在告警產生時會一同作爲參數發送到Alertmanager。

爲了讓Prometheus能夠啓用定義的告警規則，我們需要在Prometheus全局配置文件中通過rule_files指定一組告警規則文件的訪問路徑，Prometheus啓動後會自動掃描這些路徑下規則文件中定義的內容，並且根據這些規則計算是否向外部發送通知：

rule_files:
  [ - <filepath_glob> ... ]

默認情況下Prometheus會每分鐘對這些告警規則進行計算，如果用戶想定義自己的告警計算週期，則可以通過evaluation_interval來覆蓋默認的計算週期：

global:
  [ evaluation_interval: <duration> | default = 1m ]

模板化
在告警規則文件的annotations中使用summary描述告警的概要信息，description用於描述告警的詳細信息。同時Alertmanager的UI也會根據這兩個標籤值，顯示告警信息。爲了讓告警信息具有更好的可讀性，Prometheus支持模板化label和annotations的中標籤的值。

通過$labels.變量可以訪問當前告警實例中指定標籤的值。$value則可以獲取當前PromQL表達式計算的樣本值。

# To insert a firing element's label values:
{{ $labels.<labelname> }}
# To insert the numeric expression value of the firing element:
{{ $value }}

例如，可以通過模板化優化summary以及description的內容的可讀性：

groups:
- name: example
  rules:

  # Alert for any instance that is unreachable for >5 minutes.
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

查看告警狀態
如下所示，用戶可以通過Prometheus WEB界面中的Alerts菜單查看當前Prometheus下的所有告警規則，以及其當前所處的活動狀態。

同時對於已經pending或者firing的告警，Prometheus也會將它們存儲到時間序列ALERTS{}中。
可以通過表達式，查詢告警實例：

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

樣本值爲1表示當前告警處於活動狀態（pending或者firing），當告警從活動狀態轉換爲非活動狀態時，樣本值則爲0。

示例：定義主機監控報警
修改Prometheus配置文件prometheus.yml,添加以下配置：

rule_files:
  - /usr/local/prometheus/*.rules

在目錄/usr/local/prometheus/下創建告警文件alert.rules內容如下：

groups:
- name: hostStatsAlert
  rules:
  - alert: hostCpuUsageAlert
    expr: sum(avg without (cpu)(irate(node_cpu_seconds_total{mode!='idle'}[1m]))) by (instance) > 0.5
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usgae high"
      description: "{{ $labels.instance }} CPU usage above 50% (current value: {{ $value }})"
  - alert: hostMemUsageAlert
    expr: (node_memory_MemTotal - node_memory_MemAvailable)/node_memory_MemTotal > 0.85
    for: 1m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} MEM usgae high"
      description: "{{ $labels.instance }} MEM usage above 50% (current value: {{ $value }})"

重啓Prometheus後訪問Prometheus UI http://127.0.0.1:9090/rules可以查看當前以加載的規則文件。這裏我將閥值調小了，但是配置文件忘記修改不及在意。

切換到Alerts標籤http://127.0.0.1:9090/alerts可以查看當前告警的活動狀態。

此時，我們可以手動拉高系統的CPU使用率，驗證Prometheus的告警流程，在主機上運行以下命令：

cat /dev/zero>/dev/null

運行命令後查看CPU使用率情況，如下圖所示：

Prometheus首次檢測到滿足觸發條件後，hostCpuUsageAlert顯示由一條告警處於活動狀態。由於告警規則中設置了1m的等待時間，當前告警狀態爲PENDING，如果1分鐘後告警條件持續滿足，則會實際觸發告警並且告警狀態爲FIRING，如下圖所示：

3.部署AlertManager
Alertmanager和Prometheus Server一樣均採用Golang實現，並且沒有第三方依賴。一般來說我們可以通過以下幾種方式來部署Alertmanager：二進制包、容器以及源碼方式安裝。

tar xf alertmanager-0.21.0.linux-amd64.tar.gz -C /usr/local/ && cd /usr/local/
ln -s /usr/local/alertmanager-0.21.0.linux-amd64/ alertmanager
mkdir -p /usr/local/alertmanager/data/
vim /etc/systemd/system/alertmanager.service
添加如下內容：
[Unit]
Description=alertmanager
After=network.target

[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/alertmanager-0.21.0.linux-amd64/alertmanager --config.file=/usr/local/alertmanager/alert-test.
yml --storage.path=/usr/local/alertmanager/data/
Restart=on-failure

[Install]
WantedBy=multi-user.target

–config.file用於指定alertmanager配置文件路徑
–storage.path用於指定數據存儲路徑。

創建alertmanager配置文件
Alertmanager解壓後會包含一個默認的alertmanager.yml配置文件，內容如下所示：

cd /usr/local/alertmanager
cp alertmanager.yml alert-test.yml
vim alert-test.yml
內容如下：
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'web.hook'
receivers:
- name: 'web.hook'
  webhook_configs:
  - url: 'http://127.0.0.1:5001/'
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

Alertmanager的配置主要包含兩個部分：路由(route)以及接收器(receivers)。所有的告警信息都會從配置中的頂級路由(route)進入路由樹，根據路由規則將告警信息發送給相應的接收器。

在Alertmanager中可以定義一組接收器，比如可以按照角色(比如系統運維，數據庫管理員)來劃分多個接收器。接收器可以關聯郵件，Slack以及其它方式接收告警信息。
當前配置文件中定義了一個默認的接收者default-receiver由於這裏沒有設置接收方式，目前只相當於一個佔位符。

在配置文件中使用route定義了頂級的路由，路由是一個基於標籤匹配規則的樹狀結構。所有的告警信息從頂級路由開始，根據標籤匹配規則進入到不同的子路由，並且根據子路由設置的接收器發送告警。目前配置文件中只設置了一個頂級路由route並且定義的接收器爲default-receiver。因此，所有的告警都會發送給default-receiver。

Alermanager會將數據保存到本地中，默認的存儲路徑爲data/。因此，在啓動Alertmanager之前需要創建相應的目錄

啓動Alertmanager

chown -R prometheus:prometheus /usr/local/alertmanager-0.21.0.linux-amd64/
systemctl status alertmanager.service

Alertmanager啓動後可以通過9093端口訪問，http://192.168.0.10:9093

Alert菜單下可以查看Alertmanager接收到的告警內容。Silences菜單下則可以通過UI創建靜默規則.

關聯Prometheus與Alertmanager
在Prometheus的架構中被劃分成兩個獨立的部分。Prometheus負責產生告警，而Alertmanager負責告警產生後的後續處理。因此Alertmanager部署完成後，需要在Prometheus中設置Alertmanager相關的信息。

編輯Prometheus配置文件prometheus.yml,並添加以下內容：

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

重啓Prometheus服務，成功後，可以從http://192.168.0.10:9090/config查看alerting配置是否生效。

此時，再次嘗試手動拉高系統CPU使用率：

cat /dev/zero>/dev/null

等待Prometheus告警進行觸發狀態：

查看Alertmanager UI此時可以看到Alertmanager接收到的告警信息。

Prometheus學習筆記三–郵件報警規則配置

Prometheus學習筆記四–Alertmanager配置概述及路由概述

Prometheus學習筆記二–安裝部署簡單監控及使用PromQL查詢監控數據

Prometheus學習筆記三–郵件報警規則配置

Prometheus學習筆記-認識Prometheus

如何在物理機上安裝EXSI平臺經測試可用生產

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結