Prometheus集成Alertmanager实现报警

一、简介

Prometheus 是一套开源的系统监控、报警、时间序列数据库的组合，最初有 SoundCloud 开发的，后来随着越来越多公司使用，于是便独立成开源项目。Alertmanager 主要用于接收 Prometheus 发送的告警信息，它支持丰富的告警通知渠道，例如邮件、微信、钉钉、Slack 等常用沟通工具，而且很容易做到告警信息进行去重，降噪，分组等，是一款很好用的告警通知系统。

二、环境软件准备

1.下载Alertmanager组件：Download | Prometheus

2.prometheus环境搭建：见上篇Prometheus+Grafana安装并监控Linux主机及微服务文章

三、安装Alertmanager组件

1.上传组件到对应服务器

2.解压缩

tar -zxvf alertmanager-0.25.0.linux-amd64.tar.gz

3.修改配置

cd alertmanager-0.25.0.linux-amd64/

vim alertmanager.yml

global:
  resolve_timeout: 5m # 超时,默认5min
  smtp_smarthost: 'smtp.qq.com:465' # 这里为邮箱SMTP服务地址，同时要设置开启 POP3/SMTP 服务。
  smtp_from: '123456@dhl.com' #发送人邮箱
  smtp_auth_username:
  smtp_auth_password: ''
#是否使用tls，根据环境不同，来选择开启和关闭。如果提示报错 email.loginAuth failed: 530 Must issue a STARTTLS command first，那么就需要设置为 true。着重说明一下，如果开启了 tls，提示报错 starttls failed: x509: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 来跳过 tls 验证。
  smtp_require_tls: false
templates: # 模板
  - 'alert.tmp'
# route：用来设置报警的分发策略。Prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配项，因为根路由是所有告警的入口点。
# 另外，根路由需要配置一个接收器(receiver)，用来处理那些没有匹配到任何子路由的告警（如果没有配置子路由，则全部由根路由发送告警），即缺省
# 接收器。告警进入到根route后开始遍历子route节点，如果匹配到，则将告警发送到该子route定义的receiver中，然后就停止匹配了。因为在route中
# continue默认为false，如果continue为true，则告警会继续进行后续子route匹配。如果当前告警仍匹配不到任何的子route，则该告警将从其上一级(
# 匹配)route或者根route发出（按最后匹配到的规则发出邮件）。查看你的告警路由树，https://www.prometheus.io/webtools/alerting/routing-tree-editor/,
# 将alertmanager.yml配置文件复制到对话框，然后点击"Draw Routing Tree"
route:
  group_by: ['alertname'] # 用于分组聚合，对告警通知按标签(label)进行分组，将具有相同标签或相同告警名称(alertname)的告警通知聚合在一个组，然后作为一个通知发送。如果想完全禁
用聚合，可以设置为group_by: [...]
  group_wait: 30s # 当一个新的告警组被创建时，需要等待'group_wait'后才发送初始通知。这样可以确保在发送等待前能聚合更多具有相同标签的告警，最后合并为一个通知发送。
  group_interval: 1m # 当第一次告警通知发出后，在新的评估周期内又收到了该分组最新的告警，则需等待'group_interval'时间后，开始发送为该组触发的新告警，可以简单理解为，group就
相当于一个通道(channel)。
  repeat_interval: 30m # 告警通知成功发送后，若问题一直未恢复，需再次重复发送的间隔。
  receiver: 'email' #  配置告警消息接收者，与下面配置的对应。例如常用的 email、wechat、slack、webhook 等消息通知方式。
#  routes: # 子路由
#  - receiver: 'wechat'
#    match: # 通过标签去匹配这次告警是否符合这个路由节点；也可以使用  match_re 进行正则匹配
#      severity: Disaster       # 标签severity为Disaster时满足条件，使用wechat警报

receivers: # 配置报警信息接收者信息。
- name: 'email' # 警报接收者名称
  email_configs:
  - to: '{{ template "email.to"}}'  # 接收警报的email（这里是引用模板文件中定义的变量）
    html: '{{ template "email.to.html" .}}' # 发送邮件的内容（调用模板文件中的）
#    headers: { Subject: " {{ .CommonLabels.instance }} {{ .CommonAnnotations.summary }}" }     # 邮件标题，不设定使用默认的即可
    send_resolved: true  # 故障恢复后通知

#- name: 'wechat'
#  wechat_configs:
#  - corp_id: wwd76d598b5fad5097                # 企业信息("我的企业"--->"CorpID"[在底部])
#    to_user: '@all'            # 发送给企业微信用户的ID，这里是所有人
#   to_party: '' 接收部门ID
#    agent_id: 1000004  # 企业微信("企业应用"-->"自定应用"[Prometheus]--> "AgentId")
#    api_secret: DY9IlG0Bdwawb_ku0NblxKFrrmMwbLIZ7YxMa5rCg8g            # 企业微信("企业应用"-->"自定应用"[Prometheus]--> "Secret")
#    message: '{{ template "email.to.html" .}}' # 发送内容（调用模板）
#    send_resolved: true                # 故障恢复后通知
inhibit_rules: # 抑制规则配置，当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。
  - source_match:
      severity: 'inhibition'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

简单介绍一下主要配置的作用：

1.global: 全局配置，包括报警解决后的超时时间、SMTP 相关配置、各种渠道通知的 API 地址等等。
2.route: 用来设置报警的分发策略，它是一个树状结构，按照深度优先从左向右的顺序进行匹配。
receivers: 配置告警消息接受者信息，例如常用的 email、wechat、slack、webhook 等消息通知方式。
3.inhibit_rules: 抑制规则配置，当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。

邮箱配置说明：

1.smtp_smarthost: 这里为 QQ 邮箱 SMTP 服务地址，官方地址为 smtp.qq.com 端口为 465 或 587，同时要设置开启 POP3/SMTP 服务。
2.smtp_auth_password: 这里为第三方登录 QQ 邮箱的授权码，非 QQ 账户登录密码，否则会报错，获取方式在 QQ 邮箱服务端设置开启 POP3/SMTP 服务时会提示。
3.smtp_require_tls: 是否使用 tls，根据环境不同，来选择开启和关闭。如果提示报错 email.loginAuth failed: 530 Must issue a STARTTLS command first，那么就需要设置为 true。着重说明一下，如果开启了 tls，提示报错 starttls failed: x509: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 来跳过 tls 验证。

4.修改好配置使用amtool工具检查一下配置

./amtool check-config alertmanager.yml

5. 创建模板文件{alert.tmp}

vim alert.tmp

1.下边模板文件配置了 email.from、email.to、email.to.html 三种模板变量，可以在 alertmanager.yml 文件中直接配置引用。这里 email.to.html 就是要发送的邮件内容，支持 Html 和 Text 格式，这里为了显示好看，采用 Html 格式简单显示信息。下边 {{ range .Alerts }} 是个循环语法，用于循环获取匹配的 Alerts 的信息。

2.如果收件人有多个 则以','拼接即可，如：123@qq.com,456@qq.com

{{ define "email.from" }}no-reply-eship-v2-uat-alert@dhl.com{{ end }}
{{ define "email.to" }}123@qq.com{{ end }}
{{ define "email.to.html" }}
{{- if gt (len .Alerts.Firing) 0 -}}{{ range .Alerts }}
<h2>@告警通知</h2>
告警程序: prometheus_alert <br>
告警级别: {{ .Labels.severity }} <br>
告警类型: {{ .Labels.alertname }} <br>
故障主机: {{ .Labels.instance }} <br>
告警主题: {{ .Annotations.summary1 }} <br>
告警详情: {{ .Annotations.description1 }} <br>
触发时间: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }} <br>
{{ end }}{{ end -}}
{{- if gt (len .Alerts.Resolved) 0 -}}{{ range .Alerts }}
<h2>@告警恢复</h2>
告警程序: prometheus_alert <br>
故障主机: {{ .Labels.instance }}<br>
告警主题: {{ .Annotations.summary2 }}<br>
告警详情: {{ .Annotations.description2 }}<br>
告警时间: {{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}<br>
恢复时间: {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }}<br>
{{ end }}{{ end -}}
{{- end }}

6.启动alertmanager

./alertmanager --cluster.listen-address=  --config.file=alertmanager.yml

1.脚本

nohup ./alertmanager --cluster.listen-address=  --config.file=alertmanager.yml > /dev/null 2>&1 &

2.参数说明

--cluster.listen-address= 为集群配置参数，如果为单台则无法启动，不写值则认为关闭集群配置

--config.file=alertmanager.yml 为指定配置文件

7.查看AlertManager的WEB UI页面

浏览器访问地址  localhost:9093 

8.在prometheus配置alertmanagers

cd prometheus-2.36.2.linux-amd64/

vim prometheus.yml

 9.新增告警规则文件

mkdir rules

cd rules/

#此处只配置了两个如果有多个配置可以新增多个规则文件，或在一个规则文件中增加多个，此处为了清晰，分为多个配置文件，监控不同的指标

告警规则参考：promQL first tengxun promQL开箱即用_yuezhilangniao的博客-CSDN博客

vim host_down_alert.yml

groups:
- name: 主机存活告警规则
  rules:
  - alert: "主机存活告警" # 告警规则的名称（alertname）
    expr: up{job="prometheus"} == 0 # expr 是计算公式，up指标可以获取到当前所有运行的Exporter实例以及其状态，即告警阈值为up==0
    for: 1m # for语句会使 Prometheus 服务等待指定的时间, 然后执行查询表达式。（for 表示告警持续的时长，若持续时长小于该时间就不发给alertmanager了，大于该时间再发。for的值不
要小于prometheus中的scrape_interval，例如scrape_interval为30s，for为15s，如果触发告警规则，则再经过for时长后也一定会告警，这是因为最新的度量指标还没有拉取，在15s时仍会用原>来值进行计算。另外，要注意的是只有在第一次触发告警时才会等待(for)时长。）
    labels: # labels语句允许指定额外的标签列表，把它们附加在告警上。
      severity: senior
    annotations: # annotations语句指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的。
      summary1: "主机宕机"
      summary2: "主机恢复"
      description1: "{{$labels.instance}} 主机已宕机超过一分钟,prometheus已挂起,请系统管理员立即处理!"
      description2: "{{$labels.instance}} 主机恢复,prometheus已取消挂起!"

vim service_down_alert.yml

groups:
- name: 实例存活告警规则
  rules:
  - alert: "实例存活告警" # 告警规则的名称（alertname）
    expr: up{job="spring"} == 0 # expr 是计算公式，up指标可以获取到当前所有运行的Exporter实例以及其状态，即告警阈值为up==0
    for: 1m # for语句会使 Prometheus 服务等待指定的时间, 然后执行查询表达式。（for 表示告警持续的时长，若持续时长小于该时间就不发给alertmanager了，大于该时间再发。for的值不
要小于prometheus中的scrape_interval，例如scrape_interval为30s，for为15s，如果触发告警规则，则再经过for时长后也一定会告警，这是因为最新的度量指标还没有拉取，在15s时仍会用原>来值进行计算。另外，要注意的是只有在第一次触发告警时才会等待(for)时长。）
    labels: # labels语句允许指定额外的标签列表，把它们附加在告警上。
      severity: intermediate
    annotations: # annotations语句指定了另一组标签，它们不被当做告警实例的身份标识，它们经常用于存储一些额外的信息，用于报警信息的展示之类的。
      summary1: "服务下线"
      summary2: "服务恢复"
      description1: "{{$labels.instance}} 应用已失联超过一分钟,prometheus已挂起,请系统管理员立即处理!"
      description2: "{{$labels.instance}} 应用已恢复,prometheus已取消挂起!"

10.验证并查看Prometheus配置规则

./promtool check config prometheus.yml

 浏览器访问Prometheus地址：localhost:9090 

四、说明

到此处Prometheus集成AlertManager告警已经完成，在符合报警规则后Prometheus将会通知AlertManager，AlertManager将会把消息发出。

这里说明一下 Prometheus Alert 告警状态有三种状态：Inactive、Pending、Firing。

Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。
Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing 状态。
Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。