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。

 

配置完成后能够看到

在这期间就收不到报警邮件了。