prometheus 告警 java prometheus告警alertmanager

关于prometheus的告警通知，用户可以通过Prometheus的Web界面查看这些告警规则以及告警的触发状态。但是不能实时的通知到用户，无法实时监控系统状态等，所以集成了Alertmanager监控中心，当Promthues与Alertmanager集成之后，可以将告警发送到外部服务Alertmanager中并通过Alertmanager可以对这些告警进行进一步的处理，比如发邮件告知用户系统状态等。

一：alertmanager的部署

https://prometheus.io/download/ 在官网下载Alertmanager源码到服务器中，进行解压缩即可，安装过程比较简单，主要的是配置文件的配置，在后面会介绍到。

二：Alertmanager的配置

2.1: Alertmanager的主配置文件

[root@webserver2 alertmanager]# cat alertmanager.yml
global:                  #若所有的邮件配置使用相同的SMTP配置，则可以直接定义全局的SMTP配置
  smtp_smarthost: 'smtp.exmail.qq.com:25'
  smtp_from: '发件邮箱'
  smtp_auth_username: '发件用户名'
  smtp_auth_password: '授权码'
  smtp_require_tls: false

templates:
  - '/alidata/prometheus/alertmanager/tmpl/email.tmpl'
route:                   #顶级路由必须匹配所有报警，因为他要接受所有报警，再分匹配到分支路由上
  group_by: ['alertname']   #满足group_by中定义标签名称，那么这些告警将会合并为一个通知发送给接收器。
  group_wait: 1s              #同一group的等待时间，在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送
  group_interval: 5m         #同一Gourp发送告警通知的时间间隔
  repeat_interval: 3m      #在连续告警触发的情况下，重复发送告警的时间间隔
  receiver: 'default-receiver'
  routes:                 #分支路由，可设置不同的匹配规则
  - receiver: 'default-receiver'
    match:              #匹配告警规则的key:value
      severity: 'critical'

receivers:
- name: 'default-receiver'
  email_configs:
  - to: '{{ template "email.to" . }}'
    html: '{{ template "email.to.html" . }}'
    send_resolved: true  #告警解除发送恢复通知
#receivers:
#- name: 'default-receiver'
#  email_configs:
#  - to: '[e-mail]'
#    send_resolved: true  #告警解除发送恢复通知
[root@webserver2 alertmanager]#

2.2: Alertmanager的邮件模版配置文件

[root@webserver2 tmpl]# cat email.tmpl
{{ define "xx.html" }}{{ end }}
{{ define "email.from" }}[e-mail]{{ end }}
{{ define "email.to" }}[e-mail]{{ end }}
{{ define "email.to.html" }}
<style type="text/css">
table.gridtable {
    font-family: verdana,arial,sans-serif;font-size:11px;color:#333333;border-width: 1px;border-color: #666666;border-collapse: collapse;
}
table.gridtable th {
    border-width: 1px;padding: 8px;border-style: solid;border-color: #666666;background-color: #dedede;
}
table.gridtable td {
    border-width: 1px;padding: 8px;border-style: solid;border-color: #666666;background-color: #ffffff;
}
</style>
<table class="gridtable">
    <tr><td>报警项</td>
        <td>告警级别</td>
        <td>故障主机</td>
        <td>告警主题</td>
        <td>告警详情</td>
        <td>开始时间</td>
    </tr>
    {{ range $i, $alert := .Alerts }}
        <tr><td>{{ index $alert.Labels "alertname" }}</td>
            <td>{{ index $alert.Labels "severity" }}</td>
            <td>{{ index $alert.Labels "name" }}</td>
            <td>{{ index $alert.Annotations "summary" }}</td>
            <td>{{ index $alert.Annotations "description" }}</td>
            <td>{{ $alert.StartsAt }}</td>
        </tr>
    {{ end }}
</table>
{{ end }}

2.3、检查alertmanager配置文件

在代码所在目录检查配置文件是否正常

./amtool check-config alertmanager.yml

2.4 启动

[root@webserver2 alertmanager]# ./alertmanager --config.file=alertmanager.yml

Alertmanager配置完成之后就等待Prometheus推送告警的信息，进行告警邮件发出

以上是Alertmanager的报警介绍，如Prometheus结构图中的红框部分。

简单介绍，一条告警规则的开始和结束的流程
报警处理流程如下：以node-up为实例介绍
1. Prometheus Server监控目标主机上暴露的http接口（这里假设是node-up的接口），通过上述Promethes配置中心《prometheus-核心prometheus server （一）》的'scrape_interval'定义的时间间隔，定期采集目标主机上监控数据。
2. 当 node-up 不可用的时候，Server端会持续的尝试从接口中取数据，直到"scrape_timeout"时间后停止尝试。这时候把接口的状态变为“DOWN”。
3. Prometheus同时根据配置的"evaluation_interval"的时间间隔，定期（默认1min）的对Alert Rule进行评估；当到达评估周期的时候，发现 node-up 为DOWN，即UP=0为真，激活Alert，进入“PENDING”状态，并记录当前active的时间；
4. 当下一个alert rule的评估周期到来的时候，发现UP=0继续为真，然后判断警报Active的时间是否已经超出rule里的‘for’ 持续时间，如果未超出，则进入下一个评估周期；如果时间超出，则alert的状态变为“FIRING”；同时调用Alertmanager接口，发送相关报警数据。
5. AlertManager收到报警数据后，会将警报信息进行分组，然后根据alertmanager配置的“group_wait”时间先进行等待。等wait时间过后再发送报警信息。
6. 属于同一个Alert Group的警报，在等待的过程中可能进入新的alert，如果之前的报警已经成功发出，那么间隔“group_interval”的时间间隔后再重新发送报警信息。比如配置的是邮件报警，那么同属一个group的报警信息会汇总在一个邮件里进行发送。
7. 如果Alert Group里的警报一直没发生变化并且已经成功发送，等待‘repeat_interval’时间间隔之后再重复发送相同的报警邮件；如果之前的警报没有成功发送，则相当于触发第6条条件，则需要等待group_interval时间间隔后重复发送。
同时最后至于警报信息具体发给谁，满足什么样的条件下指定警报接收人，设置不同报警发送频率，这里有alertmanager的route路由规则进行配置。