Argo Rollouts metric provider plugin written in Go. Collects stable/canary pod logs and delegates AI analysis to an A2A agent. The agent fetches logs autonomously and can create GitHub issues/PRs when configured.
- Kubernetes Agent: kdubois/kubernetes-aiops-agent
- Demo Application: argo-rollouts-quarkus-demo
This plugin bridges Argo Rollouts with an autonomous Kubernetes Agent for AI-powered canary analysis. Instead of making direct LLM calls, it sends analysis requests to an agent that debugs pods, analyzes logs and metrics, identifies root causes, and creates GitHub PRs with fixes.
If using the Argo Rollouts Operator with RolloutManager:
apiVersion: argoproj.io/v1alpha1
kind: RolloutManager
metadata:
name: argo-rollouts
spec:
plugins:
metric:
- name: argoproj-labs/metric-ai
location: https://github.com/argoproj-labs/rollouts-plugin-metric-ai/releases/download/v1.9.0/rollouts-plugin-metric-ai-linux-amd64Replace v1.9.0 with the desired release version. See releases for available versions.
For manual installation without RolloutManager:
apiVersion: v1
kind: ConfigMap
metadata:
name: argo-rollouts-config
data:
metricProviderPlugins: |-
- name: "argoproj-labs/metric-ai"
location: "file://./rollouts-plugin-metric-ai/bin/metric-ai"apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: canary-analysis
spec:
metrics:
- name: ai-analysis
provider:
plugin:
argoproj-labs/metric-ai:
agentUrl: http://kubernetes-agent.argo-rollouts.svc.cluster.local:8080
stableLabel: role=stable
canaryLabel: role=canary
# Optional: Additional context for AI analysis
extraPrompt: "Focus on error patterns and performance metrics"The plugin uses the A2A protocol to delegate analysis to the Kubernetes Agent:
- Plugin collects pod labels and namespace information
- Sends A2A request to the agent
- Agent fetches logs and metrics
- Agent analyzes with AI
- Agent identifies root causes
- Agent returns structured JSON response with promote/rollback decision
- Plugin uses result to promote or abort canary
- Agent asynchronously creates GitHub PRs with fixes (if needed)
No LLM configuration needed in the plugin. The agent handles its own model configuration, log fetching, and GitHub integration. Remediation happens asynchronously after the rollout decision is made.
sequenceDiagram
box rgb(175, 202, 232) Argo Rollouts
participant AC as Controller
end
box rgb(152, 213, 151) Plugin
participant P as Plugin
end
box rgb(200, 184, 238) Kubernetes Agents
participant KA as Agent
participant DA as Diagnostic Agent
participant MA as Metrics Agent
participant AA as Analysis Agent
participant RA as Remediation Agent
end
box rgb(220, 246, 184) GitHub
participant GH as GitHub
end
AC->>P: AnalysisRun
P->>KA: HTTP POST /a2a/analyze
par Collect diagnostics
KA->>DA: Fetch logs & pod details
DA-->>KA: logs & pod details
and Collect metrics
KA->>MA: Fetch metrics
MA-->>KA: metrics
end
KA->>AA: Analyze logs, pod details & metrics
AA-->>KA: Root cause identification
KA-->>P: Return decision (promote/rollback)
P-->>AC: Promote or abort canary
KA-)RA: Ask for remediation (if needed)
alt Operational issue
RA-)GH: Create GitHub Issue
else Coding issue
RA-)GH: Create GitHub PR
end
Deploy the Kubernetes Agent in your cluster. See kdubois/kubernetes-aiops-agent for an example that runs analysis with logs and metrics and root cause identification. The agent must be accessible via HTTP from the Argo Rollouts controller.
Analysis fails if:
agentUrlis not configured- Agent is unavailable or health check fails
- A2A communication fails
No fallback mode exists.
| Field | Type | Required | Description |
|---|---|---|---|
agentUrl |
string | Yes | A2A agent URL (e.g., http://kubernetes-agent:8080) |
stableLabel |
string | Yes | Label selector for stable pods (e.g., role=stable) |
canaryLabel |
string | Yes | Label selector for canary pods (e.g., role=canary) |
githubUrl |
string | No | GitHub repository URL for issue creation |
baseBranch |
string | No | Git base branch for issue creation |
extraPrompt |
string | No | Additional context for AI analysis |
Namespace is auto-detected from AnalysisRun.
| Variable | Required | Description |
|---|---|---|
LOG_LEVEL |
No | Log level: panic, fatal, error, warn, info, debug, trace (default: info) |
The plugin doesn't need API keys. The model configuration happens in the agent setup itself.
Pass additional context to the AI via extraPrompt:
extraPrompt: "High-traffic e-commerce service. Focus on error rates, response times, and database connections. Consider business impact."Use cases:
- Performance focus: "Focus on response times and throughput"
- Error analysis: "Pay attention to error rates and exceptions"
- Business context: "Critical payment service - prioritize stability"
- Technical constraints: "Consider memory usage and connection limits"
- Ignore expected changes: "Ignore color changes in output"
# Build Go binary
make build
# Build Docker image
make docker-build
# Build multi-platform and push
make docker-buildxGitHub Actions builds and publishes multi-platform images to ghcr.io/argoproj-labs/rollouts-plugin-metric-ai:<commit-sha> on pushes to main.
See examples/ for analysis templates and ConfigMap setup.
See config/rollouts-examples/ for complete deployments with rollouts, services, and traffic generators.
Complete working examples:
- argo-rollouts-quarkus-demo - Demo app with test scenarios
- progressive-delivery - Full GitOps setup
Control log level with LOG_LEVEL environment variable.
Levels: panic, fatal, error, warn, info (default), debug, trace
Environment variable:
export LOG_LEVEL=debugKubernetes deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: argo-rollouts
spec:
template:
spec:
containers:
- name: argo-rollouts
env:
- name: LOG_LEVEL
value: "debug"Kustomize: Already configured in config/argo-rollouts/kustomization.yaml
# All logs
kubectl logs -f -n argo-rollouts deployment/argo-rollouts
# Plugin-specific
kubectl logs -n argo-rollouts deployment/argo-rollouts | grep -E "metric-ai|AI metric|plugin"
# With timestamps
kubectl logs -n argo-rollouts deployment/argo-rollouts --timestamps=trueDebug/trace levels log:
- Configuration parsing
- Pod log operations
- A2A communication
- Agent health checks
- GitHub interactions
- Performance metrics
When using the example agents
Check agent URL:
kubectl get analysistemplate -n <namespace> <template-name> -o yaml | grep agentUrlVerify agent is running:
kubectl get pods -n argo-rollouts | grep kubernetes-agent
kubectl logs -n argo-rollouts deployment/kubernetes-agentTest agent health:
# From cluster
curl http://kubernetes-agent.argo-rollouts.svc.cluster.local:8080/q/health
# Port-forward
kubectl port-forward -n argo-rollouts svc/kubernetes-agent 8080:8080
curl http://localhost:8080/q/healthNote: The agent uses /q/health which is the standard Quarkus health endpoint. This provides comprehensive health checks including readiness and liveness probes.
Check plugin logs:
kubectl logs -n argo-rollouts deployment/argo-rollouts | grep -E "agent|A2A|Attempting to create"- "agentUrl is required": Add
agentUrlto AnalysisTemplate - "Agent health check failed": Verify agent is running and accessible
- "A2A agent analysis failed": Check agent logs and network
- GitHub issue creation skipped: Check for "githubUrl not configured" in logs
- Namespace auto-detection: Uses namespace from AnalysisRun automatically
For agent-specific issues, see Kubernetes Agent Troubleshooting.
# Create Kind cluster and run e2e tests
make test
# Run e2e tests only
make test-e2e- kubernetes-aiops-agent - The AI agent
- argo-rollouts - Progressive delivery controller
- argo-rollouts-quarkus-demo - Demo application
Apache License 2.0
Fork, create feature branch, add tests, submit PR.
- Plugin issues: Create issue
- Agent issues: Create issue
- Documentation: Agent docs