Alertmanager配置概述及告警规则

在此之前,环境准备和安装我就不在重复一遍了.可以看之前的博客,这里我们直接步入正题.

Alertmanager配置概述

Alertmanager主要负责对Prometheus产生的告警进行统一处理,因此在Alertmanager配置中一般会包含以下几个主要部分:

• 全局配置(global) : 用于定义一些全局的公共参数,如全局的SMTP配置,Slack配置等内容;
• 模板(templates) : 用于定义告警通知时的模板,如HTML模板,邮件模板等;
• 告警路由(route) : 根据标签匹配,确定当前告警应该如何处理;
• 接收人(receivers) : 接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack或者Webhook等,接收人一般告警路由使用;
• 抑制规则(inhibit_rules) : 合理设置抑制规则可以减少垃圾告警的产生

global:
  #163服务器
  smtp_smarthost: 'smtp.163.com:465'
  #发邮件的邮箱
  smtp_from: 'cdring@163.com'
  #发邮件的邮箱用户名，也就是你的邮箱　　　　　
  smtp_auth_username: 'cdring@163.com'
  #发邮件的邮箱密码
  smtp_auth_password: 'your-password'
  #进行tls验证
  smtp_require_tls: false
route:
  group_by: ['alertname']
  # 当收到告警的时候，等待group_wait配置的时间，看是否还有告警，如果有就一起发出去
  group_wait: 10s
  #  如果上次告警信息发送成功，此时又来了一个新的告警数据，则需要等待group_interval配置的时间才可以发送出去
  group_interval: 10s
  # 如果上次告警信息发送成功，且问题没有解决，则等待 repeat_interval配置的时间再次发送告警数据
  repeat_interval: 10m
  # 全局报警组，这个参数是必选的
  receiver: email
receivers:
- name: 'email'
  #收邮件的邮箱
  email_configs:
  - to: 'cdring@163.com'
inhibit_rules:
 - source_match:
     severity: 'critical'
   target_match:
     severity: 'warning'
   equal: ['alertname', 'dev', 'instance']

在全局配置中需要注意的是resolve_timeout,该参数定义了Alertmanager持续多长时间未接收到告警后标记告警状态为resolved(已解决).该参数的定义可能会影响到告警恢复通知的接收时间,读者可根据自己的实际场景进行定义,其默认值为5分钟.在接下来的部分,我们将以一些实例的例子解释Alertmanager的其他配置内容.

Prometheus告警规则

Prometheus中的告警规则允许你基于PromQL表达式定义告警触发条件,Prometheus后端对这些触发规则进行周期性计算,当1满足触发条件后则会触发告警通知.默认情况下,用户可以通过Prometheus的Web界面查看这些告警规则以及告警的触发状态.当Prometheus与Alertmanager关联后,可以将告警发送到外部服务可以对这些告警进行进一步的处理.

• 告警规则是配置在Prometheus服务器

与Alertmanager关联

Prometheus把产生的告警发送给Alertmanager进行告警处理时,需要在Prometheus使用的配置文件中添加关联Alertmanager组件的对应配置内容.

1.编辑Prometheus.yml文件加入关联Alertmanager组件的访问地址,示例如下:

# Alertmanager 配置
alerting:
  alertmanagers:
  - static_configs:
    - targets: ['alertmanager:9093']

2.添加监控Alertmanager,让Prometheus去手机Alertmanager的监控指标.

- job_name: 'alertmanager'
    scrape_interval: 15s
    static_configs:
    - targets: ['alertmanager:9093']

配置告警规则文件

vim promtheus/alert.yml

告警规则配置如下:

groups:
- name: Prometheus alert
  rules:
  # 对任何实例超过30秒无法联系的情况发出警报
  - alert: 服务告警
    expr: up == 0
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "服务异常,实例:{{ $labels.instance }}"
      description: "{{ $labels.job }} 服务已关闭"

在告警规则文件中,我们可以将一组相关的规则设置定义在group下.在每一个group中我们可以定义多个告警规则(rule).一条告警规则主要由以下几部分组成:

• alert: 告警规则的名称
• expr: 基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件
• for: 评估等待时间,可选参数.用于表示只有当前触发条件持续一段时间后在发送告警.在等待时间新产生的告警的状态为pending
• labels: 自定义标签,允许用户指定要附加到告警上的一组附加标签
• annotations: 用于指定一组附加信息,比如用于描述告警详情信息的文字等,annotations的内容在告警产生时会作为参数发送到Alertmanager

指定加载告警规则

为了能够在Prometheus能够启用定义的告警规则,我们需要在Prometheus全局配置文件中通过rule_files指定一组告警规则文件的访问路径,Prometheus启动后会自动扫描这些路径下规则文件中定义的内容,并且根据这些规则计算是否向外部发送通知:

具体配置

# 报警(触发器)配置
rule_files:
  - "alert.yml"
  - "rules/*.yml"

重新加载配置

curl -x POST http://localhost:9090/-/reload

查看告警状态

重启Prometheus后,用户可以通过Prometheus WEB界面中Alerts菜单查看当前Prometheus下的所有告警规则,以及当前所处的活动状态.

同时对于以及pending或者firing的告警,Prometheus也会将它们存储到时间序列ALERTS{}中.

可以通过表达式,查询告警实例:

AlERTS{}

样本值为1表示当前告警处于活动状态(pending或者firing),当告警从活动状态转换为非活动状态时样本值为0

测试告警规则

在主机上运行以下命令

docker stop node-exporter

Prometheus首次检测到满足触发条件后,由于告警规则中设置了1分钟(for: 1m)的等待时间,告警状态由INACTIVE变为Pending,如下图所示:

如果1分钟后告警条件持续满足,告警转台从Pending变为FIRING,并且会把告警信息发送给Alertmanager.如下图所示: