作者：吴叶磊，原文链接：https://aleiwu.com/post/prometheus-alert-why/

最近又被问到了 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 的数据存储方式与计算方式。

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

如何应对

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

到此为止了吗？

Prometheus 警报不仅包含 Prometheus 本身，还包含用于警报治理的 Alertmanager，我们可以看一看上面那张指标计算示意图的全图：

官方站点：www.linuxprobe.com

Linux命令大全：www.linuxcool.com

刘遄老师QQ：5604241

Linux技术交流群：3762708

（新群，火热加群中……）

想要学习Linux系统的读者可以点击"阅读原文"按钮来了解书籍《Linux就该这么学》，同时也非常适合专业的运维人员阅读，成为辅助您工作的高价值工具书！