用错误率与延迟指标为金丝雀发布设门禁

概述

把百分之十的流量切给新版本，只有在有机制依据数据判断新版本是否正常时才有意义。否则所谓金丝雀只是等待固定时长后继续推进，等同于多绕几步的滚动更新。Argo Rollouts 的 AnalysisTemplate 会按间隔执行查询、与成功条件比较，并在失败时中止发布。关键在于选择能在用户投诉前发生变化的指标，以及在无法取数时按失败处理。

步骤

1. 定义错误率分析，超过百分之一即失败：

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: canary-error-rate
spec:
  metrics:
    - name: error-rate
      interval: 1m
      count: 5
      failureLimit: 1
      successCondition: result[0] < 0.01
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{job="payments",track="canary",status=~"5.."}[2m]))
            /
            sum(rate(http_requests_total{job="payments",track="canary"}[2m]))

2. 在金丝雀策略的低权重阶段引用该分析：

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - analysis:
          templates:
            - templateName: canary-error-rate

3. 观察失败时的中止行为：

kubectl argo rollouts get rollout payments -n prod --watch

4. 增加流量存在性检查，避免无数据时误判为通过：

- name: traffic-present
  interval: 1m
  count: 2
  successCondition: result[0] > 0
  provider:
    prometheus:
      address: http://prometheus.monitoring:9090
      query: |
        sum(rate(http_requests_total{job="payments",track="canary"}[2m]))

验证

正常情况下，发布应在 10% 权重处暂停并完成五次测量后继续；故意引入错误后，状态应变为 Degraded，流量回到 stable，分析记录标记为失败。查询必须只选择金丝雀 Pod，若聚合了全量流量，错误会被稀释而门禁失效。无流量时 traffic-present 应失败而不是返回通过。

注意事项

• 指标门禁无法发现不影响错误率与延迟的正确性问题。
• 抓取间隔与 Prometheus 保留时长决定发现回退的速度。
• failureLimit 需结合业务噪声设定，连续两次失败通常已代表真实回退。
• 分析结果应与发布记录一起保存，包含查询语句与实际数值。
• 缺少数据不等于没有错误，必须显式要求请求速率大于零。