search

实践：接收Prometheus的告警

本节我们将写一个程序，来接收Prometheus发送的告警，并将告警打印出来。

首先，我们安装好Prometheus、NodeExporter。Prometheus的配置prometheus.yml如下：

global:
  scrape_interval: 15s 
  evaluation_interval: 15s

rule_files:
  - "/usr/local/prometheus/rule_files/node.yml"

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
    - targets: ['192.168.2.101:9100']
      labels:
        IP: '192.168.2.101'

alerting:
  alertmanagers:
  - static_configs:
    - targets: [ '192.168.2.101:19093' ]

告警规则文件node.yml内容如下：

在上面的prometheus.yml中，我们配置的alertmanager的地址为192.168.2.101:19093，这个地址就是接下来我们要启动的自已的程序，用来接收prometheus的告警信息并打印出来。

在主机上的某个目录下创建文件alertmanager.go，文件内容见本文附录，然后执行命令go run alertmanager.go将程序跑起来。

接着，我们启动Prometheus与NodeExporter。

然后，我们拉高主机CPU的使用率，不一会，我们便可以在Prometheus的Alert页面看到一个告警处理Pending状态

再等一会，等告警Firing之后，我们自已的程序会接收到该告警并打印出来：可以发现，startsAt就是上面截图中的Active Since的时间，也就是Alert变成Pending的时间。endsAt刚好是startAt加了三分钟（这个暂时不清楚为什么是三分钟）。

让CPU一直保持在80%以上，我们会发现Prometheus会持续地向AlertManager发送Alert。我们发现，发送的时间间隔为75秒（为什么是75秒还不清楚，很有可能是evaluation_interval的五倍），startsAt一直没变，而endsAt一直在增加，增加的时间为Prometheus发送该告警的时间再加3m。

接着，我们把CPU降到80%以下（时间大概在20:56:28到20:56:58之间）。我们会发现，20:56:28时发送的告警（上面的最后一条），其endsAt的时间为20:59:28，说明发送该条告警时，CPU还处于80%以上。而过了30秒后，Promethus又发送了一条告警（下面第一条），这一次没有等到75秒，是因为发送该条告警时CPU已经低于80%了。

这里我们就有两个疑问了：（1）我们如何判断发送下面第一条告警时CPU已经低于80%了呢？（2）下面第一条告警中，CPU的值显示的是81.76666666656578%呀？

其实原因是很简单：我们配置了evaluation_interval的值为15秒，Prometheus在上面最后一条告警（20:56:28）后，在20:56:43和20:56:58都会做一次Evaluation，在20:56:43这一次计算出来的CPU的值为81.76666666656578%，由于上一条告警还没有过75秒，所以不发送。在20:56:58时该计算出来的CPU已经小于80%，相当于告警已经解除，于是Prometheus会立即发送一条告警出去，表明告警已解除。也就是说，下面第一条告警其实是一条“解除告警”，为什么呢？因为endsAt的时间就是发送该条告警的时间，当AlertManager接收到以后，发现这个时间已经是一个过去的时间了，也就是说，这条告警已经结束了。既然已经通过endsAt标识该告警已经过时了，那么CPU的值也就不重要了，不过Prometheus用了“解除告警”的上一次计算出来的值还有让人有点容易混淆。

另外，根据上面的输出我们还可以发现，当“解除告警”发出去以后，Prometheus还坚持把“解除告警”发送了好多次，而且时间间隔也为75秒。在实验中我们发现大概发送了十几次后，Prometheus就不再发送了。

hashtag
附录

alertmanager.go的代码

PreviousPrometheus发送告警机制Next实践：AlertManager

Last updated