关键在于用 rate() 捕捉异常突变而非绝对峰值，结合 alertmanager 分组、抑制与 slo 错误预算实现精准告警：rate(http_requests_total[5m]) 提供平滑速率，配合同比/环比变化率阈值（如 >2.5 倍 1h 均值）和 for: 2m 持续约束；alertmanager 通过 group_by、group_wait、抑制规则减少冗余通知；进阶可联动 slo 错误预算消耗速率动态触发告警。
用 rate() 配合 Alertmanager 防范业务洪峰引发的告警风暴，关键不在“压住告警”，而在于让告警真正反映异常——不是流量高，而是“高得不合理”。Prometheus 的 rate() 本身不防风暴，但它提供真实、平滑、可比的速率指标；Alertmanager 则靠分组、抑制、静默等机制过滤冗余通知。二者配合，才能把“1000 QPS 告警”变成“QPS 突增 300% 且持续 2 分钟”的精准信号。
用 rate() 抓住“突变”，而不是“峰值”
rate(http_requests_total[5m]) 返回的是过去 5 分钟的平均每秒请求数，它天然对瞬时毛刺不敏感，也消除了计数器重置影响。相比 irate()（只看最近两个点），rate() 更稳定，更适合告警场景。
- 避免写
http_requests_total > 1000这类绝对值阈值——大促期间 5000 QPS 是常态，平时 100 QPS 就算异常 - 改用变化率：比如
rate(http_requests_total[5m]) / ignoring(instance) group_left() rate(http_requests_total[1h]) > 2.5，表示当前速率是过去 1 小时均值的 2.5 倍以上 - 加持续时间约束：
for: 2m，防止秒级脉冲触发误报
Alertmanager 分组 + 延迟发送，合并同类告警
洪峰常导致多个实例同时触发相似告警（如所有 API 实例都报“请求延迟升高”）。若每台机器发一条通知，就是几十条重复消息。
- 在
alertmanager.yml中按业务维度分组：group_by: ['alertname', 'service', 'env'] - 设置
group_wait: 30s，让同一组告警先攒一攒，再合并成一条通知 - 用
group_interval: 5m控制后续同组新告警的发送节奏，避免刷屏
用抑制规则屏蔽“连带反应”
洪峰可能压垮下游依赖（如数据库连接池耗尽），进而引发大量衍生告警（DB 连接失败 → 接口超时 → 服务不可用）。这时应让核心问题“说了算”。
- 配置抑制规则：当
alertname="DatabaseConnectionExhausted"触发时，抑制同service和env下所有alertname="APIResponseLatencyHigh"告警 - 标签要对齐：确保被抑制告警和源告警共享
service、env、zone等关键标签，否则抑制无效
结合 SLO 错误预算做动态阈值（进阶）
更进一步，可将 rate() 结果与 SLO 目标联动。例如定义“API 可用性 SLO = 99.9%”，则允许每月最多 43 分钟不可用。当错误预算消耗过快（如 1 小时内已用掉 30%），才触发告警，而非只要错误率 >0.1% 就响。
- 用 PromQL 计算错误预算消耗速率：
sum(rate(http_requests_total{code=~"5.."}[1h])) by (service) / sum(rate(http_requests_total[1h])) by (service) - 告警规则中引用该比率，并设定基于预算余量的动态阈值（如“错误预算小时消耗率 > 5%”）
