个人 Prometheus 到底啥时候报警？

最近又被问到了 Prometheus 为啥不报警，刚好回忆起以前常常解答相关问题，不妨写一篇文章来解决下面两个问题：

• 个人 Prometheus 为啥报警？
• 个人 Prometheus 为啥不报警？

从 for 参数开始

---

咱们首先须要一些背景知识：Prometheus 是如何计算并产生警报的？

---

看一条简单的警报规则：

- alert: KubeAPILatencyHigh annotations: message: The API server has a 99th percentile latency of {{ $value }} seconds for {{ $labels.verb }} {{ $labels.resource }}. expr: | cluster_quantile:apiserver_request_latencies:histogram_quantile{job="apiserver",quantile="0.99",subresource!="log"} > 4 for: 10m labels: severity: critical

这条警报的*大体*含义是，假如 kube-apiserver 的 P99 响应时间大于 4 秒，并持续 10 分钟以上，就产生报警。

首先要注意的是由 `for` 指定的 Pending Duration。这个参数主要用于降噪，不少相似响应时间这样的指标都是有抖动的，经过指定 Pending Duration，咱们能够 过滤掉这些瞬时抖动，让 on-call 人员可以把注意力放在真正有持续影响的问题上。

那么显然，下面这样的情况是不会触发这条警报规则的，由于虽然指标已经达到了警报阈值，但持续时间并不够长：

但偶尔咱们也会碰到更奇怪的事情。

为何不报警？

---

(图二: 为啥不报警)

相似上面这样持续超出阈值的场景，为何有时候会不报警呢？

为何报警？

---

(图三: 为啥会报警)

相似上面这样并未持续超出阈值的场景，为何有时又会报警呢？

采样间隔

这其实都源自于 Prometheus 的数据存储方式与计算方式。

首先，Prometheus 按照配置的抓取间隔(`scrape_interval`)定时抓取指标数据，所以存储的是形如 (timestamp, value) 这样的采样点。

对于警报， Prometheus 会按固定的时间间隔重复计算每条警报规则，所以警报规则计算获得的只是稀疏的采样点，而警报持续时间是否大于 `for` 指定的 Pending Duration 则是由这些稀疏的采样点决定的。

而在 Grafana 渲染图表时，Grafana 发送给 Prometheus 的是一个 Range Query，其执行机制是从时间区间的起始点开始，每隔必定的时间点（由 Range Query 的 `step` 请求参数决定） 进行一次计算采样。

这些结合在一块儿，就会致使警报规则计算时“看到的内容”和咱们在 Grafana 图表上观察到的内容不一致，好比下面这张示意图：

上面图中，圆点表明原始采样点：

• 40s 时，第一次计算，低于阈值
• 80s 时，第二次计算，高于阈值，进入 Pending 状态
• 120s 时，第三次计算，仍然高于阈值，90s 处的原始采样点虽然低于阈值，可是警报规则计算时并无”看到它“
• 160s 时，第四次计算，高于阈值，Pending 达到 2 分钟，进入 firing 状态
• 持续高于阈值
• 直到 360s 时，计算获得低于阈值，警报消除

因为采样是稀疏的，部分采样点会出现被跳过的情况，而当 Grafana 渲染图表时，取决于 Range Query 中采样点的分布，图表则有可能捕捉到 被警报规则忽略掉的”低谷“（图三)或者也可能没法捕捉到警报规则碰到的”低谷“（图二）。如此这般，咱们就被”图表“给蒙骗过去，质疑起警报来了。

如何应对

---

首先嘛， Prometheus 做为一个指标系统天生就不是精确的——因为指标自己就是稀疏采样的，事实上全部的图表和警报都是”估算”，咱们也就没必要 太纠结于图表和警报的对应性，可以帮助咱们发现问题解决问题就是一个好监控系统。固然，有时候咱们也得证实这个警报确实没问题，那能够看一眼 `ALERTS` 指标。`ALERTS` 是 Prometheus 在警报计算过程当中维护的内建指标，它记录每一个警报从 Pending 到 Firing 的整个历史过程，拉出来一看也就清楚了。

但有时候 ALERTS 的说服力可能还不够，由于它自己并无记录每次计算出来的值究竟是啥，而在咱们回头去考证警报时，又没法选取出和警报计算过程当中如出一辙的计算时间点， 所以也就没法还原警报计算时看到的计算值到底是啥。这时候终极解决方案就是把警报所要计算的指标定义成一条 Recording Rule，计算出一个新指标来记录计算值，而后针对这个 新指标作阈值报警。kube-prometheus 的警报规则中就大量采用了这种技术。

到此为止了吗？

---

Prometheus 警报不只包含 Prometheus 自己，还包含用于警报治理的 Alertmanager，咱们能够看一看上面那张指标计算示意图的全图：

在警报产生后，还要通过 Alertmanager 的分组、抑制处理、静默处理、去重处理和降噪处理最后再发送给接收者。而这个过程也有大量的因素可能会致使警报产生了却最终 没有进行通知。这部分的内容，以前的文章 搞搞 Prometheus：Alertmanager 已经涵盖，这两篇内容加在一块儿，也算是能把开头的两个问题解答得差很少了吧😂。

做者：吴叶磊
原文：https://aleiwu.com/post/prome...

最新整理的 2TB 技术干货：包括系统运维、数据库、redis、MogoDB、电子书、Java基础课程、Java实战项目、架构师综合教程、架构师实战项目、大数据、Docker容器、ELK Stack、机器学习、BAT面试精讲视频等。在「 民工哥技术之路」微信公众号对话框回复关键字：1024便可获取所有资料。