Prometheus多指标响应时间上升PromQL告警不触发问题排查

告警一直卡pending不触发，是三个配置错误叠出来的：

• 最核心的问题是无意义使用子查询引入了不必要的数值波动，把for的连续计时反复重置清零。你要匹配所有responseTime_开头的指标计算导数，根本用不着[20s:1s]这种子查询语法，也没必要套一层label_replace。deriv()原生就支持直接传入多指标匹配的范围向量，写deriv({__name__=~"responseTime_.*"}[20s])就能实现你要的批量匹配计算效果。你额外加的1s步长子查询，会在5s间隔的真实采集点之间生成一堆线性插值的虚拟样本，而告警是按固定评估间隔（默认15s）做瞬时查询计算值的，只要评估时间点和真实采集点出现偏移，插值算出来的导数值就可能掉到0.2阈值下面，只要掉一次，for攒的连续时长就直接清零，永远凑不够1分钟的触发要求。你在监控图上看到的连续大于阈值的曲线，是监控面板按范围查询自动适配步长生成的，和告警瞬时评估的计算逻辑存在差异，才会出现图上看着没问题、告警死活不触发的偏差。
• 第二个问题是YAML缩进写错了。你贴的第二个规则里，annotations块被错误缩进至labels块内部，和serverity标签平级，下面的summary、value也会被YAML解析成标签字段，不光告警注解无法正常读取，还可能干扰规则的状态判断。
• 第三个是冗余逻辑问题，你写的label_replace属于多余操作，原始指标自带的__name__标签本来就会跟随计算结果保留，足够区分不同URL的时序，硬加个metricname标签没有任何实际作用，部分老版本Prometheus中还可能因为标签变动导致时序追踪异常，打断for的连续计时。另外你标签里的serverity存在拼写错误，正确写法是severity，虽然不影响告警触发，但属于无意义的笔误。

直接把规则替换成下面的配置即可：

groups:
- name: automatic_flow_control
  rules:
  - alert: automatic_flow_control
    expr: deriv({__name__=~"responseTime_.*"}[20s]) > 0.2
    for: 1m
    labels:
      severity: warn
    annotations:
      summary: "URL响应时间持续上升，存在潜在运行风险"
      value: "当前响应时间斜率值= {{ $value }}"
      target_metric: "{{ $labels.__name__ }}"

• 修复后去掉了多余的子查询和label_replace，所有导数计算都基于真实采集的样本点，不会有插值带来的异常波动，每个URL对应的时序标签完全固定，for的连续计时不会被异常打断。
• 修正了annotations的缩进和拼写错误，告警触发时可以直接从注解里拿到异常的指标名，方便定位具体出问题的URL。
• 你当前使用的20s计算窗口刚好匹配5s的采集间隔，能拿到4个真实样本点，满足deriv计算最小二乘斜率的样本要求，不需要调整窗口大小。

内容的提问来源于stack exchange，提问作者william