02 . Prometheus告警處理

Prometheus告警簡介

• 告警能力在Prometheus的架構中被劃分紅兩個獨立的部分。以下所示，經過在Prometheus中定義AlertRule（告警規則），Prometheus會週期性的對告警規則進行計算，若是知足告警觸發條件就會向Alertmanager發送告警信息。
  
• 在Prometheus中一條告警規則主要由如下幾部分組成：
• 告警名稱：用戶須要爲告警規則命名，固然對於命名而言，須要可以直接表達出該告警的主要內容
• 告警規則：告警規則實際上主要由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頁面上進行設置。

自定義Prometheus告警規則

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

定義告警規則

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

# 告警規則配置完成後，須要注意，還要在prometheus.yml中配置alertmanager的地址:  
vim  first_rules.yml
groups:
- name: node-up
  rules:
  - alert: node-up 
    expr: up == 0
    for: 15s
    labels:
      severity: 1
      team: node
    annotations:
      summary: "{{$labels.instance}}Instance has been down for more than 5 minutes"

vim prometheus.yml
  8 alerting:
  9   alertmanagers:
 10   - static_configs:
 11     - targets:
 12       - 127.0.0.1:9093
 13 
 14 #Load rules once and periodically evaluate them according to the globa l 'evaluation_interval'.
 15 rule_files:
 16     - "first_rules.yml"
 17   # - "second_rules.yml"
    
    
# alert：告警規則的名稱。
# expr：基於PromQL表達式告警觸發條件，用於計算是否有時間序列知足該條件。
# for：評估等待時間，可選參數。用於表示只有當觸發條件持續一段時間後才發送告警。在等待期間新產生告警的狀態爲pending。
# labels：自定義標籤，容許用戶指定要附加到告警上的一組附加標籤。
# annotations：用於指定一組附加信息，好比用於描述告警詳細信息的文字等，annotations的內容在告警產生時會一同做爲參數發送到Alertmanager。
# summary描述告警的概要信息，description用於描述告警的詳細信息。   
# 同時Alertmanager的UI也會根據這兩個標籤值，顯示告警信息。

爲了可以讓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 }}

• 例如，能夠經過模板化優化sumary以及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下的全部告警規則，以及其當前所處的活動狀態。

Alertmanager安裝和配置

alertmanager是用來接收prometheus發出的告警，而後按照配置文件的要求，將告警用對應的方式發送出去。將告警集中到alertmanager，能夠對告警進行更細緻的管理。
5.1 alertmanager的安裝和啓動

wget https://github.com/prometheus/alertmanager/releases/download/v0.19.0/alertmanager-0.19.0.linux-amd64.tar.gz

下載解壓Alertmanager包

# 從官網下載好包後咱們能夠對他進行解壓
tar xvf alertmanager-0.19.0.linux-amd64.tar.gz -C /usr/local/

啓動訪問Alertmanager

cd /usr/local/alertmanager-0.19.0.linux-amd64/
./alertmanager &>/dev/null  &

# 接下來咱們訪問http://172.19.0.51:9093/#/alerts，就能夠打開alertmanager的頁面,

編輯Alertmanager.yml

# 接下來咱們編輯alertmanager.yml文件，配置郵箱帳號受權碼相關配置
cat alertmanager.yml
global:		# 全局配置，報警策略，報警渠道等.
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: '18621048481@163.com'
  smtp_auth_username: '18621048481@163.com'
  smtp_auth_password:  'ZHOUjian22' 		# 郵箱受權碼
  smtp_require_tls: false 

route:		# 分發策略
  group_by: ['alertname'] 
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 5m
  receiver: 'email'

receivers:		# 接受者
- name: 'email'
  email_configs:
  - to: '18621048481@163.com'		# 接受的郵箱
    send_resolved: true
inhibit_rules:		# 抑制策略，當存在另外一組匹配的警報，抑制規則將禁止與另外一組匹配的警報.
  - source_match:
      serverity: 'critical'

宕掉一臺node_exporter

# 接下來咱們重啓一下服務使配置生效，而後宕掉一臺節點的node_exporter
# 將alertmanager加入到systemd服務
vim /usr/lib/systemd/system/alertmanager.service 
[Unit]
Description=Alertmanager
After=network.target

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

[Install]
WantedBy=multi-user.target

systemctl restart node_exporter
systemctl restart alertmanager
systemctl restart prometheus
# 若是服務啓動失敗報錯，能夠先systemctl daemon-reload，再重啓
# 接下來咱們將node_export停掉兩臺，而後去查看prometheus的控制面板

若是以爲這個報警界面太醜，能夠自定義模板的

自定義報警信息模板

若是不知道怎麼寫模板，能夠下載官方的模板，基於上面作修改

wget https://raw.githubusercontent.com/prometheus/alertmanager/master/template/default.tmpl

# 我這裏寫一個簡單的模板例子,須要修改兩個配置文件，而後重啓服務
cat alertmanager.yml
global:
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: '18621048481@163.com'
  smtp_auth_username: '18621048481@163.com'
  smtp_auth_password:  'ZHOUjian21' 
  smtp_require_tls: false 

templates:
  - '/usr/local/alertmanager-0.19.0.linux-amd64/template/*.tmpl'

route:
  group_by: ['alertname','cluster','service'] 
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 5m
  receiver: 'email'

receivers:
- name: 'email'
  email_configs:
  - to: '18621048481@163.com'
    html: '{{ template "email.mengyuan.html" . }}'
    headers: { Subject: "[WARN] 報警郵件 test" }
    send_resolved: true
inhibit_rules:
  - source_match:
      serverity: 'critical'

cat template/default.tmpl {{ define "email.mengyuan.html" }}
<table>
    <tr><td>報警名</td><td>開始時間</td></tr>
    {{ range $i, $alert := .Alerts }}
        <tr><td>{{ index $alert.Labels "alertname" }}</td><td>{{ $alert.StartsAt }}</td></tr>
    {{ end }}
</table>
{{ end }}
systemctl restart alertname
systemctl restart prometheus
# 接下來咱們模擬一臺節點宕機了，而後去郵箱查看,忽然發現其實服務自帶的模板挺好看的.