企业灰度发布 12：Prometheus 自动判定与回滚，怎样避免指标陷阱

“错误率大于 1% 就回滚”听起来明确，实际可能在低流量时被一次错误触发，也可能在指标采集断线时把空结果当成功，还可能因为 stable 同时受共享数据库故障影响而误判 canary。自动化放大了规则质量：好的规则缩短恢复时间，坏的规则会自动制造发布震荡。

发布分析不是 Dashboard 截图，而是一份可执行的统计与业务契约。它必须定义查询对象、观察窗口、最小样本、成功/失败条件、连续失败次数、缺失数据语义和人工升级路径。

指标要分成四层

第一层是平台健康：canary 副本是否 ready、实际流量是否到达、Envoy 是否配置同步、Prometheus 抓取是否新鲜。平台层失败不应被解释成业务版本失败，而应暂停发布并修复观测链。

第二层是服务 RED：请求率、错误率、延迟分布。它快速发现技术回归，但要按 route、cluster、version/release 过滤，并排除健康检查等噪声。

第三层是资源饱和：CPU throttling、内存、GC、线程池、连接池和队列。它更适合阻止继续扩大，而不一定立即回滚；例如 CPU 高可能只是 canary 副本太少，需要先扩容再重测。

第四层是业务结果：订单提交、支付授权、搜索零结果率、登录成功和收入损失。它决定“HTTP 成功是否真的有价值”，也通常需要更长窗口和事件链聚合。

错误率要先聚合分子与分母

多实例错误率不能对每个 Pod 的百分比直接求平均，因为请求量不同。应先分别汇总错误请求和总请求，再相除。例如经典 counter 可以写成：

sum(rate(istio_requests_total{
  destination_workload="checkout-canary",
  response_code=~"5.*"
}[5m]))
/
clamp_min(sum(rate(istio_requests_total{
  destination_workload="checkout-canary"
}[5m])), 0.001)

还要定义哪些响应算失败。客户端取消、限流 429、应用 4xx、代理 503 和业务拒绝的含义不同。把所有非 2xx 合在一起，会把正常风控拒绝误判为版本错误；只看 5xx 又会漏掉新版本错误返回 200 的业务回归。

P95 不能靠平均多个 Summary quantile

各 Pod 暴露的 summary quantile="0.95" 无法正确聚合，avg() 得到的是没有统计意义的数。应使用可聚合 histogram，先汇总 bucket 再用 histogram_quantile()，或者在支持时使用 native histogram。

histogram_quantile(
  0.95,
  sum by (le) (
    rate(http_request_duration_seconds_bucket{
      release="canary"
    }[5m])
  )
)

Bucket 要围绕 SLO 阈值设计；过宽会让分位数误差过大。大型平台可把常用表达式做成 recording rules，降低每个 AnalysisRun 的查询成本，并用 promtool 对规则做语法和单元测试。

小样本与低流量怎样处理

5% 流量每分钟只有 10 个请求时，99% 成功率没有足够分辨率。分析前先设置最小请求数；不足时可延长观察、运行合成负载、提高灰度比例到受控内部人群，或进入人工复核。绝不能把“没有错误”误写成“成功率 100%”。

对于零流量，平台应区分三种原因：业务本来低峰、路由未生效、指标丢失。先检查入口总量和 observed canary traffic，再判断是否允许推进。NaN、空向量、查询超时都应有显式策略，默认暂停通常比默认通过安全。

基线比较比固定阈值更抗环境噪声

共享依赖变慢时，stable 与 canary 可能同时从 200ms 上升到 600ms。固定 500ms 阈值会回滚 canary，却不能解决数据库事故。可以同时使用绝对门槛和相对门槛：canary 必须满足 SLO，且相对 stable 的错误率或延迟不能恶化超过容忍度。

但比较组也会偏差。Header 灰度的内部用户、地域、设备和请求路径与普通流量不同；stable QPS 高、canary QPS 低，分布不等方差。平台应记录分流策略，让分析模板知道是随机百分比、固定 cohort 还是 shadow，而不是套用同一统计规则。

快回滚与慢指标要分层

容器崩溃、5xx 激增、核心接口完全不可用属于 fast fail，可以数十秒内 abort。P95、转化率、消息积压需要分钟到小时观察。退款率、留存等长周期指标不适合阻塞一次 Kubernetes Release，应进入后发布监控和 feature flag 决策。

AnalysisTemplate 应成为平台产品

不要让每个团队复制 PromQL。平台按服务类型提供有版本的模板：HTTP 在线服务、gRPC、消息消费者、定时任务、核心交易。模板声明必需 label、最小流量、默认窗口和失败动作；业务团队只补充 SLO 与业务指标。模板升级先在历史数据回放，评估误报与漏报。

每次判定应保存查询、参数、原始结果、时间范围、Prometheus 实例、规则版本和最终解释。只有保存证据，事故后才能回答“为什么系统当时自动通过/回滚”。

自动化准入底线

下一篇把单服务 Canary 扩展到微服务调用链。Header 进入 A-v2 后，怎样让 A 调用 B、C 时仍留在同一灰度泳道，同时避免身份伪造、泳道爆炸与隐性回落。

参考资料

• Argo Rollouts：Analysis
• Argo Rollouts：Prometheus Metric Provider
• Prometheus：Histograms and summaries
• Prometheus：Recording rules
• Prometheus：Alerting practices