prometheus告警插件-alertmanager

prometheus自己不支持告警功能，主要經過插件alertmanage來實現告警。AlertManager用於接收Prometheus發送的告警並對於告警進行一系列的處理後發送給指定的用戶。

prometheus觸發一條告警的過程：

prometheus--->觸發閾值--->超出持續時間--->alertmanager--->分組|抑制|靜默--->媒體類型--->郵件|釘釘|微信等。

配置alertmanager

• 安裝alertmanager。https://github.com/prometheus/alertmanager/releases/download/v0.16.2/alertmanager-0.16.2.linux-amd64.tar.gz

• 配置告警信息   vim alertmanager.yml

  global:
    resolve_timeout: 5m
    smtp_smarthost: 'smtp.163.com:25'
    smtp_from: 'xxx@163.com'
    smtp_auth_username: 'xxx@163.com'
    smtp_auth_password: 'xxxxxx'
    smtp_require_tls: false
  
  route:   # route用來設置報警的分發策略
    group_by: ['alertname']  # 採用哪一個標籤來做爲分組依據
    group_wait: 10s   # 組告警等待時間。也就是告警產生後等待10s，若是有同組告警一塊兒發出
    group_interval: 10s  # 兩組告警的間隔時間
    repeat_interval: 20m  # 重複告警的間隔時間，減小相同郵件的發送頻率
    receiver: 'default-receiver'  # 設置默認接收人
    routes:   # 能夠指定哪些組接手哪些消息
    - receiver: 'default-receiver'  
      continue: true
      group_wait: 10s
    - receiver: 'fping-receiver'  
      group_wait: 10s
      match_re:  #根據標籤分組，匹配標籤dest=szjf的爲fping-receiver組
        dest: szjf
  
  receivers:
  - name: 'default-receiver'
    email_configs:
    - to: 'xxxxxxxx@qq.com'
  - name: "fping-receiver"
    webhook_configs:
    - url: 'http://127.0.0.1:9095/dingtalk'
      send_resolved: true

   

注意：以前報警了可是郵件一直沒有發送出去，# telnet smtp.163.com 25發現也不通，發現是騰訊雲作了限制，須要點擊25端口解封。 

啓動alertmanage

   # ./amtool check-config alertmanager.yml   # 檢查配置
　　Checking 'alertmanager.yml' SUCCESS
　　Found:
　　- global config
　　- route
　　- 0 inhibit rules
　　- 1 receivers
　　- 0 templates

   #  ./alertmanager --config.file='alertmanager.yml'   # 啓動

 web ui查看 ： http://alertmanager_ip:9093

 

配置prometheus與alertmanager通訊 

# vim prometheus.yml

alerting:
  alertmanagers:  # 配置alertmanager
  - static_configs: - targets: - 127.0.0.1:9093 #alertmanager服務器ip端口 rule_files: # 告警規則文件 - 'rules/*.yml'

 配置報警規則rules

# vim rules/node.yml

groups:
- name: test rules: - alert: 內存使用率太高 expr: 100-(node_memory_Buffers_bytes+node_memory_Cached_bytes+node_memory_MemFree_bytes)/node_memory_MemTotal_bytes*100 > 30 for: 1m # 告警持續時間，超過這個時間纔會發送給alertmanager labels: severity: warning annotations: summary: "Instance {{ $labels.instance }} 內存使用率太高" description: "{{ $labels.instance }} of job {{$labels.job}}內存使用率超過80%,當前使用率[{{ $value }}]." - alert: cpu使用率太高 expr: 100-avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance)*100 > 0 for: 1m labels: severity: warning annotations: summary: "Instance {{ $labels.instance }} cpu使用率太高" description: "{{ $labels.instance }} of job {{$labels.job}}cpu使用率超過80%,當前使用率[{{ $value }}]."
# 儘量把詳細告警信息寫入summary標籤值，由於告警短信/郵件/釘釘發送的內容使用了summary標籤中的值。

檢查告警規則，重啓prometheus

# ./promtool check rules rules/node.yml 
　　Checking rules/node.yml
　　SUCCESS: 2 rules found

  amtool 管理工具能夠查看：

# ./amtool alert --alertmanager.url=http://localhost:9093
Alertname            Starts At                Summary                              
內存使用率太高    2019-04-09 13:14:45 CST   Instance 192.168.1.12:9100 內存使用率太高  

 在prometheus界面的alert能夠看到告警狀態。

• 綠色表示正常。
• 紅色狀態爲 PENDING表示alerts 尚未發送至 Alertmanager，由於rules裏面配置了for: 1m。
• 1分鐘後狀態由 PENDING 變爲 FIRING，此時，prometheus纔將告警發給alertmanager，在 Alertmanager 中能夠看到有一個 alert。 

收到郵件：

 

告警收斂（分組，抑制，靜默）

• 分組(group): 將相似性質的警報合併爲單個通知。

  group_by: ['alertname']  # 以標籤做爲分組依據
  group_wait: 10s    # 分組報警等待時間
  group_interval: 10s   # 發送組告警間隔時間
  repeat_interval: 1h  # 重複告警發送間隔時間

•    抑制(inhibition): 當警報發出後，中止重複發送由此警報引起的其餘警報。能夠消除冗餘告警

inhibit_rules:
  - source_match:  # 當此告警發生，其餘的告警被抑制
      severity: 'critical'   
    target_match:   # 被抑制的對象
      severity: 'warning'  
    equal: ['id', 'instance']

• 靜默(silences): 是一種簡單的特定時間靜音的機制。例如：服務器要升級維護能夠先設置這個時間段告警靜默。

           靜默在alertmanager的web界面silence裏面配置，create silence。

 

配置完成後能夠看到

在這期間就收不到報警郵件了。