prometheus rabbitmq告警规则 prometheus告警抑制

一、告警级别

在rules告警规则中，根据不同的阈值制定不同的告警等级。

告警严重度	关键字
严重	critical、disaster、blocker、immediate、fatal、crit、sev0、'sev 0'、p0
高	E、H、high、err、error、urgent、major、'sev 1'、sev1、p1
中	M、medium、unknown、warn、warning、'not classified'、average、normal、'sev 2'、sev2、p2
低	L、I、info、information、suggestion、minor、informational、'sev 3'、sev3、p3
报告	report、dbg、debug、verbose、trivial、page、ok、'sev 4'、sev4、p4

二、Prometheus告警升级

一般会使用warning、critical和emergency三种等级依次递增，来实现告警升级。        

groups:
- name: Rules
  rules:

      - alert: CPU使用情况
        expr: 100-(avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance)* 100) > 60
        for: 1m
        labels: {resType: 'Node',severity: 'warning'}
        annotations:
          summary: "{{$labels.mountpoint}} CPU使用率过高！CPU使用大于60%(目前使用:{{$value}}%)"
          description: "{{$labels.mountpoint }} CPU使用大于60%(目前使用:{{$value}}%)"

      - alert: CPU使用情况
        expr: 100-(avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance)* 100) > 80
        for: 1m
        labels: {resType: 'Node',severity: 'critical'}
        annotations:
          summary: "{{$labels.mountpoint}} CPU使用率过高！CPU使用大于60%(目前使用:{{$value}}%)"
          description: "{{$labels.mountpoint }} CPU使用大于60%(目前使用:{{$value}}%)

三、Alertmanager告警抑制

Inhibition 抑制
抑制是当出现其它告警的时候压制当前告警的通知，可以有效的防止告警风暴。
比如当机房出现网络故障时，所有服务都将不可用而产生大量服务不可用告警，但这些警告并不能反映真实问题在哪，真正需要发出的应该是网络故障告警。当出现网络故障告警的时候，应当抑制服务不可用告警的通知。

针对高级别进行告警
#1、创建不通级别
[root@master1 alertmanager-0.22.2.linux-amd64]# vim ../prometheus-2.24.0.linux-amd64/rules/alertrules.yaml 
groups:
- name: alertrules
  rules:
  - alert: instanceMemHigh
    expr: instance:node_mem:percent > 5 
    for: 1m
    annotations: 
      summary: "{{ $labels.instance }} mem is too high !"
      description: "instance's memory is too high, Plealse check. instance={{ $labels.instance }} severity={{ $externalLabels.alertLevel }}"
    labels:
      alertLevel: page
      namespace: com
  - alert: instanceCpuHigh
    expr: instance:node_cpu:avg_rate5m > 5
    for: 1m
    annotations: 
      summary: "{{ $labels.instance }} CPU is too high !"
      description: "instance's cpu is too high, Plealse check. instance={{ $labels.instance }} job={{ $labels.alertname }}"
    labels:
      alertLevel: page
  - alert: instanceMemHigh
    expr: instance:node_mem:percent > 10 
    for: 1m
    annotations: 
      summary: "{{ $labels.instance }} mem is too high ! values is {{ $value }}"
      description: "instance's memory is too high, Plealse check. instance={{ $labels.instance }} severity={{ $externalLabels.alertLevel }}"
    labels:
      alertLevel: critical
[root@master1 alertmanager-0.22.2.linux-amd64]# curl http://127.0.0.1:9090/-/reload -XPOST

注：这里针对内存告警创建了2个级别，page和critical

#2、区分告警
[root@master1 alertmanager-0.22.2.linux-amd64]# cat alertmanager.yml 
route:
  group_by: ['alertname','alertLevel']
  group_wait: 30s
  group_interval: 2m
  repeat_interval: 5m
  receiver: 'webhook'
receivers:
- name: 'webhook'
  webhook_configs:
  - url: 'http://127.0.0.1:8086/dingtalk/webhook1/send'
inhibit_rules:
  - source_match: 
      alertLevel: 'critical'
    target_match: #必须被抑制的告警
      alertLevel: 'page'
    equal: ['alertname']
这个配置文件作用为对相同 alertName的 告警 针对alertLevel为'critical'级别的内容进行告警，alertLevel为'papge'的进行屏蔽

例如：当集群中的某一个主机节点异常宕机导致告警NodeDown被触发，同时在告警规则中定义了告警级别severity=critical。由于主机异常宕机，该主机上部署的所有服务，中间件会不可用并触发报警。根据抑制规则的定义，如果有新的告警级别为severity=critical，并且告警中标签node的值与NodeDown告警的相同，则说明新的告警是由NodeDown导致的，则启动抑制机制停止向接收器发送通知。

- source_match:
  alertname: NodeDown
  severity: critical
target_match:
  severity: critical
equal:
  - node

四、实战演示

目的：如果 NodeMemoryUsage 报警触发，则抑制NodeLoad指标规则引起的报警。

 inhibit_rules:
  - source_match:
      alertname: NodeMemoryUsage
      severity: critical
    target_match:
      severity: normal
    equal:
      - instance

效果：当告警名为NodeMemorUsage发生时，抑制告警告级为normal，以及labels标签instance与NodeMemorUsage相同的项目告警

五、完整的alertmanager-config.yml文件

apiVersion: v1
data:
  config.yml: |
    global:
      # 当alertmanager持续多长时间未接收到告警后标记告警状态为 resolved
      resolve_timeout: 5m
      # 配置邮件发送信息
      smtp_smarthost: 'smtp.163.com:25'
      smtp_from: '[e-mail]'
      smtp_auth_username: '[e-mail]'
      smtp_auth_password: 'zmkang830316'
      smtp_require_tls: false
			######################告警抑制内容#############################
    inhibit_rules:
    - source_match:
        alertname: NodeMemoryUsage
        severity: critical
      target_match:
        severity: normal
      equal:
        - instance
    # 所有报警信息进入后的根路由，用来设置报警的分发策略
    route:
      # 接收到的报警信息里面有许多alertname=NodeLoadHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
      group_by: ['alertname']
      # 当一个新的报警分组被创建后，需要等待至少 group_wait 时间来初始化通知，如果在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送
      group_wait: 30s

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

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

      # 上面所有的属性都由所有子路由继承，并且可以在每个子路由上进行覆盖。
      routes:
      - receiver: critical_alerts
        group_wait: 10s
        match:
          severity: critical
      - receiver: normal_alerts
        group_wait: 10s
        match_re:
          severity: normal|middle
    # 配置告警接收者的信息
    receivers:
    - name: 'default'
      email_configs:
      - to: '[e-mail]'
        send_resolved: true
    - name: 'critical_alerts'    #严重告警级别发送给[e-mail]
      email_configs:
      - to: '[e-mail]'
        send_resolved: true
    - name: 'normal_alerts'    #普通告警级别发送给[e-mail]
      email_configs:
      - to: '[e-mail]'
        send_resolved: true  #接受告警恢复的通知
kind: ConfigMap
metadata:
  name: alertmanager
  namespace: monitor

六、Alertmanager告警静默