Argo AnalysisTemplates: Reusable Health Checks for Deployments
An AnalysisTemplate is a reusable recipe for judging a deployment's health. During a canary rollout, Argo uses it to query metrics like error rates to decide whether to promote or roll back the new version.
WHY IT EXISTS: Manually checking dashboards during a deployment is slow, error-prone, and doesn't scale. Teams needed a way to codify their release quality gates, automating the decision to promote or roll back a new version based on live system metrics instead of human intervention.
THE MENTAL MODEL: An AnalysisTemplate is like a doctor's checklist for a patient (your new application version). It's a reusable, pre-written set of tests to run, like "check temperature" (query latency) or "check blood pressure" (query error rate). The Rollout is the doctor who runs the tests and decides if the patient is healthy enough to be discharged (receive 100% of traffic).
HOW IT WORKS: You define an AnalysisTemplate as a Kubernetes custom resource. Inside, you specify one or more metrics, such as a Prometheus query for HTTP 5xx errors. You set conditions like failureLimit or consecutiveSuccessLimit to define the pass/fail criteria. Your Rollout resource then references this template. When the Rollout reaches an analysis step, it creates an AnalysisRun from the template. The Argo Rollouts controller executes the queries in the AnalysisRun, compares results against the thresholds, and then either promotes, pauses, or aborts the rollout.
WHEN TO USE IT: Use AnalysisTemplates to automate quality gates in any progressive delivery pipeline managed by Argo Rollouts. They are ideal for standardizing release criteria across multiple services. For example, all backend APIs might use a standard "API Health" template that checks error rates and latency. A ClusterAnalysisTemplate can be used to share a single template across all namespaces in a cluster.
WHEN NOT TO USE IT: Avoid AnalysisTemplates for one-off, highly specific checks that won't be reused; for those, define the analysis inline directly within the Rollout spec. They are not a replacement for a comprehensive observability platform; they are a tool for making automated decisions during a deployment, not for general system monitoring.
ONE CANONICAL EXAMPLE: A common template checks the 5xx error rate of a canary deployment. The template defines a Prometheus query like sum(rate(http_requests_total{status_code=~"5.."}[1m])). The analysis might run every 30 seconds with a failure condition like result[0] > 0.01. If the error rate ever exceeds 1%, the analysis fails, and the rollout is automatically aborted, preventing a faulty version from being fully promoted.
Read the original → argoproj.github.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.