Prometheus入门到放弃(6)之AlertManager进阶

前面几个篇幅,我们介绍了alertmanger报警配置,在实际运维过程中,我们都会遇到,报警的重复发送,以及报警信息关联性报警。接下来我们就介绍下通过alertmanger对告警信息的收敛。
一、告警分组(Grouping)
1.1 定义三个报警规则:

文中为了实验验证,告警值设置比较小,实际生产中,应该跟据业务的实际使用场景,来确定合理的告警值

[root@prometheus-server ~]# vim /etc/prometheus/rules/node_alerts.yml 

groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up{job='node'} == 0
    for: 2m
    labels:
      severity: "critical"
      env: dev
    annotations:
      summary: Host {{ $labels.instance }} of {{ $labels.job }} is Down!
  - alert: OSLoad
    expr: node_load1 > 1
    for: 2m
    labels:
      severity: "warning"
      env: dev
    annotations:
      summary: "主机 {{ $labels.instance }} 负载大于 1"
      description: "当前值: {{ $value }}"
  - alert: HightCPU
    expr: 100-avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)*100 > 10
    for: 2m
    labels:
      severity: "warning"
    annotations:
      summary: "主机 {{ $labels.instance }} of CPU 使用率大于10%!"
      description: "当前值: {{ $value }}%"

以上3个报警规则,node_alerts是监控node_exporter服务状态,OSLoad是监控系统负载,HightCPU是监控系统cpu使用率,前两个有标签env: dev,后面2个有标签 severity: "warning",重启Prometheus服务,可以看到监控规则已经加载

Prometheus入门到放弃(6)之AlertManager进阶_第1张图片  

 1.2 定义alertmanager报警组:

[root@prometheus-server ~]# vim /etc/alertmanager/alertmanager.yml
global: smtp_smarthost:
'smtp.163.com:25' smtp_from: '****@163.com' smtp_auth_username: '****@163.com' smtp_auth_password: '****' ## 授权码 smtp_require_tls: false route: group_by: ['env'] ### 以标签env分组,拥有labels为env的规则,如果在指定时间同时报警,报警信息会合并为一条进行发送 group_wait: 10s   ### 组报警等待,等待该组中有没有其它报警
group_interval: 30s ### 组报警时间间隔 repeat_interval: 2m ### 重复报警时间,这个生产中跟据服务选择合适的时间 receiver: dev
-mail ## 接收者 receivers: - name: 'dev-mail' ## 对应上面的接收者 email_configs: - to: '****@vanje.com.cn'

 1.3 验证

  我们停掉一台主机node_exporter(10.10.0.12)服务,用压测工具使某一台机器(10.10.0.11)负载大于1,cpu使用率(10.10.0.11)大于10,看下报警邮件是否会按我们定义组进行报警:

  虽然我们同时触发了三个报警,但是跟据我们的定义,应该只会发两条报警信息,因为拥有env标签的报警规则,同时报警,会被合并为一条发送。

  触发报警查看Prometheus ui界面上的alerts:

   Prometheus入门到放弃(6)之AlertManager进阶_第2张图片

    等2分钟后,如果检测到机器还是处于触发告警状态,Prometheus把会告警信息发送至alertmanager,然后跟据报警定义进行邮件报警:

   Prometheus入门到放弃(6)之AlertManager进阶_第3张图片

Prometheus入门到放弃(6)之AlertManager进阶_第4张图片

 

 上图从alertmanager报警界面可以看到,报警信息已经按照分组合并,接下来我们看下邮箱中报警信息:

Prometheus入门到放弃(6)之AlertManager进阶_第5张图片

Prometheus入门到放弃(6)之AlertManager进阶_第6张图片

分组总结:

  1、alertmanager跟据标签进行分组时,应该选择合适的标签,标签可以自定义,也可以使用默认的标签。

  2、alertmanager报警分组,可以有效减少告警邮件数,但是仅是在同一个时间段报警,同一个组的告警信息才会合并发送。

 二、告警抑制(Inhibition)

  2.1 修改Prometheus 报警规则文件,为报警信息添加新标签area: A

[root@prometheus-server ~]# vim /etc/prometheus/rules/node_alerts.yml 
groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up{job='node'} == 0
    for: 2m
    labels:
      severity: "critical"
      env: dev
      area: A
    annotations:
      summary: Host {{ $labels.instance }} of {{ $labels.job }} is Down!
  - alert: OSLoad
    expr: node_load1 > 0.6
    for: 2m
    labels:
      severity: "warning"
      env: dev
      area: A
    annotations:
      summary: "主机 {{ $labels.instance }} 负载大于 1"
      description: "当前值: {{ $value }}"
  - alert: HightCPU 
    expr: 100-avg(irate(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)*100 > 10
    for: 2m  
    labels: 
      severity: "warning"
      area: A
    annotations:
      summary: "主机 {{ $labels.instance }} of CPU 使用率大于10%!"
      description: "当前值: {{ $value }}%"

   2.2 修改alertmanager配置文件

[root@prometheus-server ~]# vim /etc/alertmanager/alertmanager.yml
## 新增以下配置
inhibit_rules:
- source_match: ## 源报警规则 severity: 'critical' target_match: ## 抑制的报警规则 severity: 'warning' equal: ['area'] ## 需要都有相同的标签及值,否则抑制不起作用

2.3 验证

跟上面一样手动触发三个规则告警,跟据定义规则,应该只会收到一条报警信息:

查看Prometheus告警都已经触发,状态变为PENDING状态

Prometheus入门到放弃(6)之AlertManager进阶_第7张图片

等待2分钟后, 三个告警状态由PENDING 变为 FIRING,同时prometheus会把告警信息发给alertmanager。

Prometheus入门到放弃(6)之AlertManager进阶_第8张图片

Alertmanager中我们只看到一条InstanceDown报警信息。

Prometheus入门到放弃(6)之AlertManager进阶_第9张图片

  查看邮件中,也只收到InstanceDown的报警,另外2条报警已经被配置的抑制规则,把报警信息忽略掉。

Prometheus入门到放弃(6)之AlertManager进阶_第10张图片

 抑制总结:

  1、抑制是指当警报发出后,停止重复发送由此警报引发其他错误的警报的机制。(比如网络不可达,服务器宕机等灾难性事件导致其他服务连接相关警报);

  2、配置抑制规则,需要合理源规则及需要抑制的规则;

  3、源规则与抑制规则需要具有相同的标签及标签值;

转载于:https://www.cnblogs.com/tchua/p/11133809.html

你可能感兴趣的:(Prometheus入门到放弃(6)之AlertManager进阶)