← Concepts

阅读中文版本

Canary Analysis: Judging a Release by Its Metrics

Canary analysis compares a small slice of production traffic against a baseline and promotes or rolls back automatically, replacing opinion with measurable criteria.

delivery

Definition

Canary analysis is an automated release step that routes a small percentage of traffic to a new version and evaluates predefined metrics against a control group. If the canary degrades, the system rolls back without waiting for a human.

Context and scope

Progressive delivery tools such as Flagger, Argo Rollouts, and Spinnaker implement it, but the hard part is choosing metrics and thresholds stable enough to trust.

Common misconceptions

  • A canary is a percentage rollout — a rollout shifts traffic; analysis decides whether it may continue
  • Any metric works — noisy or low-volume metrics produce false promotions and false rollbacks
  • Automation removes the need for judgment — thresholds encode judgment and need review

Anti-patterns

  • Analysing a canary on metrics with too little traffic to be significant
  • Comparing the canary to a baseline running on different infrastructure
  • Auto-promoting when the analysis job fails to collect data

Related concepts

Related examples

Authoritative source

https://sre.google/workbook/canarying-releases/

From traffic shift to decision

A canary release sends a small share of production traffic to a new version. Canary analysis is the step that decides what happens next: it compares the canary’s behavior with a control group and either promotes, pauses, or rolls back. Without analysis, a canary is only a slower rollout with the same human judgment at the end.

Choosing metrics

Good canary metrics are fast, sensitive, and available at low volume: error rate, latency percentiles, saturation, and business counters such as successful checkouts. A metric that only moves after an hour cannot gate a ten-minute canary. A metric that is mostly noise will fail healthy releases and train teams to ignore the gate.

For example, comparing p99 latency on a canary that receives two percent of traffic often produces wild swings, because a handful of slow requests move the percentile. Use averages over the window, or require a minimum sample count before judging.

Baseline discipline

The comparison is only meaningful if canary and baseline differ in exactly one variable: the version. Different node pools, instance sizes, or time zones introduce confounders that make results unreadable. Run both groups simultaneously, and keep the split stable for the whole analysis window.

Failure modes and rollback

Analysis jobs fail too: metrics backends time out, labels drift, and dashboards return empty series. Treat missing data as a failed check, never as a pass. Define rollback as the default outcome, and verify that rollback path regularly, because the moment you need it is the worst moment to discover it is broken.

Compared to blue-green

Blue-green switches all traffic at once and relies on pre-production testing. Canary analysis observes real users and limits exposure, but requires traffic volume and reliable metrics. Teams often combine them: blue-green for the infrastructure switch, canary analysis for the final promotion.