prometheus告警问题分析

2021-04-08 13:40:28 浏览数 (1)

今天来说一下我在使用prometheus过程中遇到的告警问题。

问题分析

最近运维prometheus的过程中发现,有的时候它应该发送告警,可实际却没有;有的时候,不该发送告警却发送了;还有的时候,告警出现明显的延迟。为了找出其中的具体原因,特地去查阅了一些资料,同时也参考了官网的相关资料。希望对大家在今后使用prometheus有所帮助。

先来看一下官网提供的prometheus和alertmanager的一些默认的重要配置。如下所示:

代码语言:javascript复制
# promtheus
global:
  # How frequently to scrape targets by default. 从目标抓取监控数据的间隔
  [ scrape_interval: <duration> | default = 1m ]
  # How long until a scrape request times out. 从目标住区数据的超时时间
  [ scrape_timeout: <duration> | default = 10s ]
  # How frequently to evaluate rules. 告警规则评估的时间间隔
  [ evaluation_interval: <duration> | default = 1m ]
# alertmanager
# How long to initially wait to send a notification for a group
# of alerts. Allows to wait for an inhibiting alert to arrive or collect
# more initial alerts for the same group. (Usually ~0s to few minutes.)
[ group_wait: <duration> | default = 30s ] # 初次发送告警的等待时间

# How long to wait before sending a notification about new alerts that
# are added to a group of alerts for which an initial notification has
# already been sent. (Usually ~5m or more.)
[ group_interval: <duration> | default = 5m ] 同一个组其他新发生的告警发送时间间隔

# How long to wait before sending a notification again if it has already
# been sent successfully for an alert. (Usually ~3h or more).
[ repeat_interval: <duration> | default = 4h ] 重复发送同一个告警的时间间隔

通过上面的配置,我们来看一下整个告警的流程。通过流程去发现问题。

根据上图以及配置来看,prometheus抓取数据后,根据告警规则计算,表达式为真时,进入pending状态,当持续时间超过for配置的时间后进入active状态;数据同时会推送至alertmanager,在经过group_wait后发送通知。
告警延迟或频发

根据整个告警流程来看,在数据到达alertmanager后,如果group_wait设置越大,则收到告警的时间也就越长,也就会造成告警延迟;同理,如果group_wait设置过小,则频繁收到告警。因此,需要按照具体场景进行设置。

不该告警的时候告警了

prometheus每经过scrape_interval时间向target拉取数据,再进行计算。与此同时,target的数据可能已经恢复正常了,也就是说,在for计算过程中,原数据已经恢复了正常,但是被告警跳过了,达到了持续时间,就触发了告警,也就发送了告警通知。但从grafana中看,认为数据正常,不应发送告警。这是因为grafana以prometheus为数据源时,是range query,而不是像告警数据那样稀疏的。

0 人点赞