prometheus告警问题的示例分析

本篇文章为大家展示了prometheus告警问题的示例分析，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

问题分析

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

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

# promtheus global:   # How frequently to scrape targets by default. 从目标抓取监控数据的间隔   [ scrape_interval:  | default = 1m ]   # How long until a scrape request times out. 从目标住区数据的超时时间   [ scrape_timeout:  | default = 10s ]   # How frequently to evaluate rules. 告警规则评估的时间间隔   [ evaluation_interval:  | 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:  | 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:  | 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:  | 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，而不是像告警数据那样稀疏的。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。

上述内容就是prometheus告警问题的示例分析，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。