Prometheus一条告警是怎么触发的

文章来源：爱可生云数据库
做者：张沈波

大纲

第一节：监控采集、计算和告警
第二节：告警分组、抑制、静默
告警分组
告警抑制
告警静默
收敛小结
第三节：告警延时
延时的三个参数
延时小结
总结

Prometheus+Grafana是监控告警解决方案里的后起之秀，好比你们熟悉的PMM，就是使用了这个方案；前不久罗老师在3306pi公众号上就写过完整的使用教程《构建狂拽炫酷屌的MySQL 监控平台》，因此咱们在这里就再也不赘述具体如何搭建使用。

今天咱们聊一些Prometheus几个有意思的特性，这些特性能帮助你们更深刻的了解Prometheus的一条告警是怎么触发的；本文提纲以下：

监控采集，计算和告警
告警分组，抑制和静默
告警延时

第一节 监控采集、计算和告警
·
Prometheus以scrape_interval（默认为1m）规则周期，从监控目标上收集信息。其中scrape_interval能够基于全局或基于单个metric定义；而后将监控信息持久存储在其本地存储上。

Prometheus以evaluation_interval（默认为1m）另外一个独立的规则周期，对告警规则作按期计算。其中evaluation_interval只有全局值；而后更新告警状态。

其中包含三种告警状态：

·inactive：没有触发阈值
·pending：已触发阈值但未知足告警持续时间
·firing：已触发阈值且知足告警持续时间

举一个例子，阈值告警的配置以下：

·收集到的mysql_uptime>=30,告警状态为inactive
·收集到的mysql_uptime<30,且持续时间小于10s，告警状态为pending
·收集到的mysql_uptime<30,且持续时间大于10s，告警状态为firing

⚠ 注意：配置中的for语法就是用来设置告警持续时间的；若是配置中不设置for或者设置为0，那么pending状态会被直接跳过。

那么怎么来计算告警阈值持续时间呢，须要回到上文的scrape_interval和evaluation_interval，假设scrape_interval为5s采集一次信息；evaluation_interval为10s；mysql_uptime告警阈值须要知足10s持续时间。

如上图所示：
Prometheus以5s（scrape_interval）一个采集周期采集状态；
而后根据采集到状态按照10s（evaluation_interval）一个计算周期，计算表达式；
表达式为真，告警状态切换到pending；
下个计算周期，表达式仍为真，且符合for持续10s，告警状态变动为active，并将告警从Prometheus发送给Altermanger；
下个计算周期，表达式仍为真，且符合for持续10s，持续告警给Altermanger；
直到某个计算周期，表达式为假，告警状态变动为inactive，发送一个resolve给Altermanger，说明此告警已解决。

第二节 告警分组、抑制、静默

第一节咱们成功的把一条mysql_uptime的告警发送给了Altermanger;可是Altermanger并非把一条从Prometheus接收到的告警简简单单的直接发送出去；直接发送出去会致使告警信息过多，运维人员会被告警淹没；因此Altermanger须要对告警作合理的收敛。

如上图，蓝色框标柱的分别为告警的接收端和发送端；这张Altermanger的架构图里，能够清晰的看到，中间还会有一系列复杂且重要的流程，等待着咱们的mysql_uptime告警。

下面咱们来说Altermanger很是重要的告警收敛手段。

·分组：group
·抑制：inhibitor
·静默：silencer

1.告警分组

告警分组的做用
·同类告警的聚合帮助运维排查问题
·经过告警邮件的合并，减小告警数量

举例来讲：咱们按照mysql的实例id对告警分组；以下图所示，告警信息会被拆分红两组。

·mysql-A

mysql_cpu_high

·mysql-B

mysql_uptime
 mysql_slave_sql_thread_down
 mysql_slave_io_thread_down

实例A分组下的告警会合并成一个告警邮件发送；
实例B分组下的告警会合并成一个告警邮件发送；

经过分组合并，能帮助运维下降告警数量，同时能有效聚合告警信息，帮助问题分析。

2.告警抑制

告警抑制的做用

·消除冗余的告警

举例来讲：同一台server-A的告警，若是有以下两条告警，而且配置了抑制规则。

·mysql_uptime
·server_uptime

最后只会收到一条server_uptime的告警。

A机器挂了，势必致使A服务器上的mysql也挂了；如配置了抑制规则，经过服务器down来抑制这台服务器上的其余告警；这样就能消除冗余的告警，帮助运维第一时间掌握最核心的告警信息。

3.告警静默

告警静默的做用

阻止发送可预期的告警

举例来讲：夜间跑批时间，批量任务会致使实例A压力升高；咱们配置了对实例A的静默规则。

·mysql-A

qps_more_than_3000
  tps_more_than_2000
  thread_running_over_200

·mysql-B

thread_running_over_200

最后咱们只会收到一条实例B的告警。

A压力高是可预期的，周期性的告警会影响运维判断；这种场景下，运维须要聚焦处理实例B的问题便可。

收敛小结
这一节，咱们mysql_uptime同窗从Prometheus被出发后，进入了Altermanger的内部流程，并无如预期的被顺利告出警来；它会先被分组，被抑制掉，被静默掉；之因此这么作，是由于咱们的运维同窗很忙很忙，精力很是有限；只有mysql_uptime同窗证实本身是很是重要的，咱们才安排它和运维同窗会面。

第三节 告警延时

第二节咱们提到了分组的概念，分组势必会带来延时；合理的配置延时，才能避免告警不及时的问题，同时帮助咱们避免告警轰炸的问题。

咱们先来看告警延时的几个重要参数：

group_by:分组参数，第二节已经介绍，好比按照[mysql-id]分组
group_wait:分组等待时间，好比：5s
group_interval:分组尝试再次发送告警的时间间隔，好比：5m
Repeat_interval: 分组内发送相同告警的时间间隔，好比：60m

延时参数主要做用在Altermanger的Dedup阶段，如图：

1.延时的三个参数

咱们仍是举例来讲，假设以下：

·配置了延时参数：

group_wait:5s
      group_interval:5m

repeat_interval: 60m
·有同组告警集A，以下：

a1
      a2
      a3

·有同组告警集B，以下：

b1
      b2

场景一：

1.a1先到达告警系统，此时在group_wait:5s的做用下，a1不会马上告出来，a1等待5s，下一刻a2在5s内也触发，a1,a2会在5s后合并为一个分组，经过一个告警消息发出来；
2.a1,a2持续未解决，它们会在repeat_interval: 60m的做用下，每隔一小时发送告警消息。

场景二：

1.a1,a2持续未解决，中间又有新的同组告警a3出现，此时在group_interval:5m的做用下，因为同组的状态发生变化，a1,a2,a3会在5min中内快速的告知运维，不会被收敛60min（repeat_interval）的时间；
2.a1,a2,a3如持续无变化，它们会在repeat_interval: 60m的做用下，再次每隔一小时发送告警消息。

场景三：

1.a1,a2发生的过程当中，发生了b1的告警，因为b1分组规则不在集合A中，因此b1遵循集合B的时间线；
2.b1发生后发生了b2，b1,b2按照相似集合A的延时规则收敛，可是时间线独立。

延时小结

经过三个延时参数，告警实现了分组等待的合并发送（group_wait），未解决告警的重复提醒（repeat_interval），分组变化后快速提醒（group_interval）。

总结

本文经过监控信息的周期性采集、告警公式的周期性计算、合并同类告警的分组、减小冗余告警的抑制、下降可预期告警的静默、同时配合三个延时参数，讲解了Prometheus的一条告警是怎么触发的；固然对于Prometheus，还有不少特性能够实践；如您有兴趣，欢迎联系咱们，咱们是爱可生。

PS：云树Umon，针对大集群监控告警作了大量的易用性的改造；一键图形化部署安装、图形化配置Prometheus，告别羞涩的yaml配置、同时提供完善的告警统计分析视图等特性，也一样欢迎你们体验~

精选文章汇总：
MySQL中间件性能测试 I
MySQL性能诊断实践之系统观测工具
Prometheus一条告警是怎么触发的
多从库时半同步复制不工做的BUG分析
大规模集群之告警系统实践
安全考虑，binlog_row_image建议尽可能使用FULL
多从库时半同步复制不工做的BUG分析
MySQL瓶颈分析与优化
使用VS Code调试MySQL