prometheus 告警机制 -（为什么告警发的不及时）

为什么告警有时发的及时，有时发的慢

数据异常到监控发出告警的时间与多个参数相关，包括采集间隔，扫描间隔，group 发送间隔，告警持续时间 for 等。 最长的时间为 采集间隔 + 扫描间隔 + group 发送间隔 + 告警持续时间 for。 默认采集间隔，扫描间隔均为 60s，group 发送间隔设置为 30s，告警持续时间 1min。告警的最长最短时间为

• 最长时间为 60s + 60s + 30s + 1min = 3min30s；
• 告警的最短时间为 0s+0s+0s+1min=1min。

告警的生命周期

1. 定期采集监控数据
2. 定期扫描告警规则，发现告警发给 alertmanager，prometheus 页面能看到 alert ，状态为 pending
3. 多次发送到 alertmanager，持续时长超过告警告警规则的 for 的 alert，prometheus 页面看到状态为 firing，准备发送。
4. firing 状态的 alert 等待 group_interval 时间聚合发送。

在这里插入图片描述

pending 状态告警

在这里插入图片描述

firing 状态告警

在这里插入图片描述

比如服务器内存超过 80%，持续 30s 发送告警。发送告警阶段如下

1. 12:00:00 服务器内存使用 90%，达到告警值
2. 12:00:10 promethues 开始采集，得到内存监控数据
3. 12:00:20 promethues 开始扫描告警规则，发现内存使用量符合告警规则，发送告警信息给 alertmanager，此时告警处于 pending 状态，不会发送。
4. 12:01:10 promethues 开始第二次采集，得到内存使用量数据。
5. 12:01:20 promethues 开始第二次扫描告警规则，发现告警持续，计算持续时间超过 30s, 告警状态为 firing，准备发送告警。
6. 12:01:50 group 聚合时间到，告警聚合发送。

虽然 12:00:30 就应该发出告警，实际在一分半之后的 12:01:50 才发出。

相关配置

alert: PodDown 
expr: min_over_time(kube_pod_container_status_ready{pod!~".*job.*|backup.*|minio-backup.*|clean-docker|dynamic-index-patterns|node-shell.*|.*jenkins.*"} [1m])== 0  
for: 1s # 持续多久确认报警信息
labels:
  group: CAAS
  severity: warning
annotations:
  summary: 'Container: {{ $labels.container }} down'
  message: 'Namespace: {{ $labels.namespace }}, Pod: {{ $labels.pod }} 服务不可用'

global:
  scrape_interval:     15s  # 数据采集时间，默认一分钟
  evaluation_interval: 15s  # 规则扫描时间，默认一分钟


group_wait: 10s # 分组等待的时间
group_interval: 30s # 上下两组发送告警的间隔时间。比如有同组的告警A和告警B，如果A触发告警，会等待30s，如果B在等待时间内也出发告警，会合并在一起发送，如果告警A 触发两次，告警A 发送后，30s 之后在发告警A第二次触发
repeat_interval: 12h # 重发间隔