【博客623】Prometheus一条告警的触发流程与等待时间

文章详细介绍了Prometheus的告警触发流程,包括数据采集间隔、评估周期和超时时间。当告警触发后,进入PENDING状态,经过一定时间评估后转为FIRING状态,Alertmanager接收到告警后,依据group_wait和group_interval进行分组和间隔发送。重复发送间隔由repeat_interval设定。group_wait和group_interval分别控制新告警组的发送延迟和同一组内告警的重发间隔。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Prometheus一条告警的触发流程与等待时间

1、与告警等待时间相关的参数

prometheus.yml

global:
  # 数据采集间隔
  scrape_interval:     15s 
  # 评估告警周期
  evaluation_interval: 15s 
 # 数据采集超时时间默认10s
 # scrape_timeout

alertmanager.yml

# route标记:告警如何发送分配
route:
  # group_by:采用哪个标签作为分组的依据
  group_by: ['alertname']
  # group_wait:分组等待的时间
  group_wait: 10s
  # group_interval:上下两组发送告警的间隔时间
  group_interval: 10s
  # repeat_interval:重复发送告警时间。默认1h
  repeat_interval: 1m
  # receiver 定义谁来通知报警
  receiver: 'mail'

2、报警处理流程:

  • 1、Prometheus通过scrape_interval定义的时间间隔,定期采集目标主机上监控数据。
  • 2、当目标不可用的时候,Server端会持续的尝试从目标metrics接口中取数据,直到"scrape_timeout"时间后停止尝试。这时候把对象的状态变为“DOWN”。
  • 3、Prometheus同时根据配置的"evaluation_interval"的时间间隔,定期(默认1min)的对Alert Rule进行评估;当到达评估周期的时候,发现接口A为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时间间隔后重复发送。

3、抓取,评估和警报

在这里插入图片描述

4、告警的生命周期

在这里插入图片描述
在这里插入图片描述

5、alertmanager部分等待分析

在这里插入图片描述
在这里插入图片描述

注意:group_wait与group_interval的重要区别

即:group_wait决定每一个新告警组需要等待多久才发送出去,group_interval决定同一个告警组的告警间隔。因此一条告警到了alertmanager如果是一个新组那么等待group_wait的时间,如果是加入了已经有的组,那么这个组是新组则等待group_wait的时间,否则等待group_interval的时间

### 如何使用 Prometheus 监控 MySQL 部署教程最佳实践 #### 安装和配置 Prometheus 和 Exporter 为了实现对 MySQL 的有效监控,通常会采用专门设计用于 MySQL 的 exporter 工具来收集指标数据。Prometheus 社区提供了官方支持的 mysqld_exporter[^2]。 mysqld_exporter 是一个 Go 编写的程序,它连接到 MySQL 实例并暴露一组标准度量供 Prometheus 抓取: ```bash wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.13.0/mysqld_exporter-0.13.0.linux-amd64.tar.gz tar xvfz mysqld_exporter-* ./mysqld_exporter --web.listen-address=":9104" --config.my-cnf=/etc/mysql/debian.cnf ``` 上述命令下载了最新版本的 mysqld_exporter 并启动服务监听端口 9104 上运行。 #### 更新 Prometheus 配置文件 编辑 `prometheus.yml` 文件,在 scrape_configs 下添加如下 job 条目以便让 Prometheus 能够抓取来自 mysqld_exporter 的数据: ```yaml scrape_configs: - job_name: 'mysql' static_configs: - targets: ['localhost:9104'] ``` 保存更改后的配置文件,并重启 Prometheus 使新设置生效: ```bash systemctl restart prometheus systemctl status prometheus ``` #### 设置告警规则 创建自定义 alert.rules 文件定义针对 MySQL 性能问题触发的通知条件。例如当 InnoDB 行等待时间超过设定阈值时发出警告通知管理员处理潜在瓶颈情况。 ```yaml groups: - alert: MysqlInnodbRowLockTimeMaxTooHigh expr: rate(mysql_innodb_row_lock_time_max[5m]) > 1000 for: 1m labels: severity: warning annotations: summary: "Mysql Innodb Row Lock Time Max Too High (instance {{ $labels.instance }})" description: "{{ $value | humanize }} is greater than the threshold of 1k over 5 minutes." ``` 此段 YAML 文本描述了一个简单的告警规则集合,其中包含一条名为"MysqlInnodbRowLockTimeMaxTooHigh"的具体告警规则。 通过以上步骤可以完成基于 Prometheus 对 MySQL 数据库实例的基础监控体系搭建工作,从而帮助运维人员及时发现性能异常状况并采取相应措施加以解决。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值