9 分组告警

真实的场景中，我们往往期望可以给告警设置级别，而且可以实现不同的报警级别可以由不同的receiver接收告警消息。Alertmanager中路由负责对告警信息进行分组匹配，并向告警接收器发送通知。以下为本次需要实现的目的

1、添加两个不同的告警级别的告警规则

• 当节点服务器 cpu15 分钟负载低于1时，发生告警，告警级别 normal（标签）
• 当节点服务器内存使用率高于 20% 时，发生告警，告警级别 normal（标签）
• 当 Prometheus Targetstatus 状态为 down 时，发生告警，告警级别 critical 和 normal（标签），因为要发送至多个不同的人

2、根据不同告警级别，发生给不同级别或部门的运维人员

• 默认将所有告警发送至

• 基础运维人员使用 as953027255@qq.com 该邮箱，也就是说所有的告警信息都发送给这个邮箱，接收 normal、critical 级别

• 领导使用邮箱 17749962670@163.com 一般都是 critical 级别的才接收

9.1 配置 alert manager

先来到 altermanager 服务器上配置 route 和告警分组

root@node2:/apps/alertmanager# vim alertmanager.yml 
global:
  # 当alertmanager持续多长时间未接收到告警后标记告警状态为 resolved
  resolve_timeout: 5m
  # 配置邮件发送信息
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_from: 'as953027255@qq.com'
  smtp_auth_username: 'as953027255@qq.com'
  smtp_auth_password: 'dzttglimanhrbeae'
  smtp_hello: '@qq.com'
  smtp_require_tls: false

# 所有报警信息进入后的根路由，用来设置报警的分发策略
route:
  # 接收到的报警信息里面有许多alertname=NodeLoadHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
  group_by: ['alertname']
  # 当一个新的报警分组被创建后，需要等待至少 group_wait 时间来初始化通知，如果在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送
  group_wait: 30s

  # 相同的group发送告警通知的时间间隔
  group_interval: 30s
  # 如果一个报警信息已经发送成功了，等待 repeat_interval 时间来重新发送
  repeat_interval: 10m

  # 必须指定默认的receiver：如果一个报警没有被一个route匹配，则发送给默认的接收器
  receiver: default

  ####################以下为本次设置的重点环节######################

  # 上面所有的属性都由所有子路由继承，并且可以在每个子路由上进行覆盖。
  routes:
  - receiver: critical_alerts   # 定义告警级别接收者 17749962670
    group_wait: 10s
    match:
      severity: critical
  - receiver: normal_alerts      # 定义告警级别接收者发送给 as953027255
    group_wait: 10s
    match_re:
      severity: normal|middle

# 配置告警接收者的信息
receivers:
- name: 'default'
  email_configs:
  - to: 'as953027255@qq.com'  # 如果有多个接收者需要用 , 隔开
    send_resolved: true
- name: 'critical_alerts'    # critical_alerts 严重告警级别发送给 17749962670@163.com
  email_configs:
  - to: '17749962670@163.com' # 如果有多个接收者需要用 , 隔开
    send_resolved: true
- name: 'normal_alerts'    # normal_alerts 普通告警级别发送给 as953027255@qq.com
  email_configs:
  - to: 'as953027255@qq.com' # 如果有多个接收者需要用 , 隔开
    send_resolved: true  #接受告警恢复的通知

# 抑制的规则相同级别的告警只发送一条
inhibit_rules:      
  - source_match:  
      severity: 'critical'      # 只发送严重级别比较高的通知其他就不会在发送
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

2.检查语法

root@node2:/apps/alertmanager# ./amtool check-config alertmanager.yml 
Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 3 receivers
 - 0 templates

3.重启 alter manager

root@node2:/apps/alertmanager# systemctl restart alertmanager.service 

9.2 配置 Prometheus rules 文件实现分组告警

配置告警实现将那些告警发送至对应的分组

1.编辑 Prometheus 配置文件

root@server:/apps/prometheus# vim prometheus.yml 
# 指定告警文件路径
rule_files:
  - "/apps/prometheus/alert_rules.yaml"

# 配置 alter manager 服务器
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - 10.0.0.137:9093

2.编写告警文件

root@server:/apps/prometheus# vim alert_rules.yaml 

groups:
# 对基础运维告警
  - name: node_status                # 分组名node_metrics
    rules:
    # node_metrics组下的监控告警规则
    - alert: NodeLoad
      # CPU 负载小于 1 就发送告警给基础运维同事
      expr: node_load15 < 1
      for: 2m
      labels:
        severity: normal          # 标签应用
      annotations:
        summary: "{{$labels.instance}}: 基础运维！Low node load detected"
        description: "{{$labels.instance}}: 基础运维！node load is below 1 (current value is: {{ $value }}"

    # node_metrics组下的监控告警规则
    - alert: NodeMemoryUsage
      # 对内存使用超过 20% 的告警，发送给基础运维同事
      expr: (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) / node_memory_MemTotal_bytes * 100 > 20
      for: 2m
      labels:
        severity: normal        # 标签应用
      annotations:
        summary: "{{$labels.instance}}: 基础运维！High Memory usage detected"
        description: "{{$labels.instance}}: 基础运维！Memory usage is above 20% (current value is: {{ $value }}"

    # 这里和领导的告警规则一样，但是由于基础运维的同事也需要看到这条告警所以也需要添加
    - alert: TargetStatus
      # 监控指标
      expr: up == 0
      for: 1m
      labels:
        severity: normal      # 标签应用
      annotations:
        summary: "{{$labels.instance}}: 基础运维！prometheus target down"
        description: "{{$labels.instance}}: 基础运维！prometheus target down，job is {{$labels.job}}"


# 对运维领导实现告警
  - name: targets_status        # 分组名targets_status 监控 exporter 状态是否为 up 如果不是则发送给运维领导
    rules:
    - alert: TargetStatus       # 分组名targets_status下的TargetStatus
      # 监控指标
      expr: up == 0
      for: 1m
      labels:
        severity: critical      # 标签应用
      annotations:
        summary: "{{$labels.instance}}: 运维领导！prometheus target down"
        description: "{{$labels.instance}}: 运维领导！prometheus target down，job is {{$labels.job}}"

3.检查语法

root@server:/apps/prometheus# ./promtool  check config prometheus.yml 
Checking prometheus.yml
  SUCCESS: 1 rule files found

Checking /apps/prometheus/alert_rules.yaml
  SUCCESS: 4 rules found

4.重新加载 Prometheus

root@server:/apps/prometheus# systemctl reload prometheus.service 

9.3 web 访问

通过 web 访问 ruler 已经生效

cpu 负载和节点 内存使用已经告警

9.4 验证邮件告警

9.4.1 验证基础运维

由于刚才上面 cpu 负载和节点 内存使用已经告警，所以这时候我们登录到基础运维的邮箱上查看邮件

内存超过 20% 告警

cpu 负载小于 1 告警

但是这个时候由于 node 节点状态还是 up 所以运维领导是收不到邮件的

9.4.2 验证运维领导和基础运维

这个时候我们将停掉一台 node-exporter 服务观察是否会对运维领导和基础运维告警

1.停掉一套 node-exporter

root@node:~# systemctl stop  node-exporter.service 

2.查看 Prometheus web 页面已经拿到对应的告警

3.验证基础运维邮箱已经成功收到

4.领导运维已经成功收到

以上就是 Prometheus 的分组告警功能