用prometheus做监控,从告警事件发生到我们收到告警信息中间经历了很多流程,了解其中的流程及相关的时间配置,就能更及时、高效的获取告警信息。
以下记录下prometheus告警生命周期/流程、相关配置参数和告警案例说明。
下面这张图是整个prometheus的流程全景图,能清晰的了解prometheus的告警运转流程。
参数名称 | 说明 | 默认值 | 参数所属 |
---|---|---|---|
scrape_interval | 指标数据采集间隔 | 1分钟 | prometheus.yml |
evaluation_interval | 规则的计算间隔 | 1分钟 | prometheus.yml |
for: 时间 | 异常持续多长时间发送告警 | 0 | 规则配置 |
group_wait | 分组等待时间。同一分组内收到第一个告警等待多久开始发送,目的是为了同组消息同时发送 | 30秒 | alertmanager.yml |
group_interval | 上下两组发送告警的间隔时间。第一次告警发出后等待group_interval时间,开始为该组触发新告警 | 5分钟 | alertmanager.yml |
repeat_interval | 重发间隔。告警已经发送,且无新增告警,再次发送告警需要的间隔时间 | 4小时 | alertmanager.yml |
监控Kafka节点是否down掉。
指标名:kakfa_up_status
1存活 0挂掉了
# prometheus.yml配置
global:
scrape_interval: 20s
evaluation_interval: 30s
# 规则配置
- alert: kakfa_down
expr: kakfa_up_status == 0
for: 1m
annotations:
summary: "Kafka挂掉了"
# alertmanager配置
route:
group_by: [alertname]
group_wait: 60s
group_interval: 5m
repeat_interval: 10m
10:00:05 Kafka挂掉了
10:00:20 拉取指标kakfa_up_status=0
10:00:30 计算规则,发现Kafka挂掉了,将kakfa_down设置为pending
10:00:30~10:01:30 持续拉取指标、计算规则
10:01:30 kafka_down持续时间达到了1分钟,设置为firing,发送到alertmanager
10:01:30 alertmanager收到后,等待分组等待时间
10:02:30 分组等待时间完成,发出告警
10:12:30 告警还没有解决,重复发出告警
prometheus 告警机制 -(为什么告警发的不及时) https://blog.csdn.net/luo4105/article/details/123700003
多久可以收到prometheus的告警? https://www.jianshu.com/p/b3b4e68409e0
prometheus告警group_wait&repeat_interval https://blog.csdn.net/tryyourbest0928/article/details/115337984