arn-infra-monitor

Arness Infra Monitor

Set up observability for deployed infrastructure: structured logging, metrics collection, and alerting. This skill recommends an observability stack based on the configured cloud provider, generates IaC for monitoring resources, and configures basic health-check-based alerts.

This skill focuses on initial monitoring setup and critical alerts. It does NOT create full monitoring dashboards (out of scope per spec). For ongoing monitoring and alerting customization, refer users to their provider's monitoring console.

Prerequisites

Read ## Arness from the project's CLAUDE.md. If no ## Arness section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run /arn-infra-wizard to get started — it will set everything up automatically." Do not proceed without it.

Check the Deferred field. If Deferred: yes, inform the user: "Infrastructure is in deferred mode. Monitoring setup is not available until infrastructure is fully configured. Run /arn-infra-assess to un-defer." Stop.

Extract:

• Experience level -- derived from user profile. Read ~/.arness/user-profile.yaml (or .claude/arness-profile.local.md if it exists — project override takes precedence). Apply the experience derivation mapping from ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md. If no profile exists, check for legacy Experience level in ## Arness as fallback.
• Providers -- cloud providers in use
• Providers config -- path to providers.md for per-provider details
• Default IaC tool -- for generating monitoring IaC
• Environments -- environment list for per-environment monitoring config
• Environments config -- path to environments.md
• Tooling manifest -- path to tooling-manifest.json
• Resource manifest -- path to active-resources.json for checking deployed resource state (if available from prior deployments)
• Cost threshold -- for monitoring cost considerations

Workflow

Step 1: Assess Current Monitoring State

Scan for existing monitoring configurations:

Glob **/cloudwatch*.tf
Glob **/monitoring*.tf
Glob **/alerting*.tf
Glob **/datadog*.tf
Glob **/grafana*.tf
Glob **/prometheus*.yml
Glob **/alertmanager*.yml
Glob docker-compose*.yml

Check deployed resources (if available):

Read <resource-manifest-path>

If existing monitoring is detected: Present: "I found existing monitoring configuration: [list]. I can extend this with additional alerts and logging."

If no monitoring is detected: Continue to Step 2 for fresh monitoring setup.

Step 2: Recommend Observability Stack

Read the local override or plugin default for observability-stack-guide.md.

Based on the configured provider(s) and experience level, recommend a monitoring approach:

Expert: Present all options: "Here are the observability options for your [provider] setup:

Native monitoring:

• [Provider-native option] -- tightest integration, included in cloud costs

Third-party options:

• [Datadog / Grafana Cloud / New Relic] -- richer features, cross-cloud visibility, additional cost

Which approach do you prefer?"

Intermediate: Present the recommended stack: "For [provider], I recommend:

• Logging: [provider-native logging service] -- captures application and infrastructure logs
• Metrics: [provider-native metrics] -- tracks resource utilization and application performance
• Alerting: [provider-native alerting] -- notifies you when things go wrong

This uses your cloud provider's built-in tools, so there are no additional services to manage. Would you like to proceed, or would you prefer a third-party solution?"

Beginner: Make the recommendation directly: "I'll set up monitoring using [provider's native tools]. This gives you logging, metrics, and alerts without any extra services or costs beyond your cloud provider."

Stack selection per provider:

• AWS --> CloudWatch (Logs, Metrics, Alarms) + SNS (notifications)
• GCP --> Cloud Logging + Cloud Monitoring + Cloud Alerting
• Azure --> Azure Monitor (Log Analytics + Metrics + Alerts)
• Kubernetes --> Prometheus + Grafana (or provider-native)
• PaaS (Fly.io, Railway, etc.) --> Platform-native logging + external alerting (PagerDuty, OpsGenie, or email)
• Multi-cloud --> Grafana Cloud or Datadog (unified view)

Step 3: Configure Logging

Guide the setup of structured logging for the deployment:

Application logging:

• Structured log format (JSON) for machine parsing
• Log levels: ERROR, WARN, INFO, DEBUG
• Correlation IDs for request tracing
• Sensitive data redaction (no PII, no secrets in logs)

Infrastructure logging:

• CloudTrail / Cloud Audit Logs / Azure Activity Log (API call auditing)
• VPC Flow Logs (AWS) / VPC Flow Logs (GCP) / NSG Flow Logs (Azure) (network monitoring)
• Access logs for load balancers, CDNs, API gateways

Log retention per environment: | Environment | Retention | Rationale | |-------------|-----------|-----------| | Dev | 7 days | Cost optimization | | Staging | 30 days | Debugging window | | Production | 90 days | Compliance (SOC 2 minimum) |

Step 4: Configure Metrics Collection

Set up metrics collection for key infrastructure components:

Core metrics to collect:

• Compute: CPU utilization, memory usage, disk I/O
• Network: Request count, response time, error rate, bandwidth
• Database: Connection count, query latency, replication lag
• Queue/Cache: Queue depth, cache hit rate, eviction rate
• Application: Health check status, request latency (p50, p95, p99), error rate

Custom metrics (optional for expert users):

• Business metrics (orders processed, users active)
• Infrastructure drift metrics (planned vs. actual state)
• Cost metrics (daily spend by resource tag)

Step 5: Configure Alerting

Read the local override or plugin default for alerting-patterns.md.

Set up alerts for critical conditions:

Essential alerts (configured for all experience levels):

| Alert | Metric | Threshold | Severity | |-------|--------|-----------|----------| | Service down | Health check | 3 consecutive failures | Critical | | High error rate | HTTP 5xx rate | > 5% of requests for 5 min | Critical | | High CPU | CPU utilization | > 80% for 10 min | Warning | | High memory | Memory utilization | > 85% for 10 min | Warning | | Disk space | Disk usage | > 80% for 15 min | Warning | | High latency | Response time p99 | > 1s for 5 min | Warning | | Critical latency | Response time p99 | > 3s for 5 min | Critical |

Notification channels:

Ask (using AskUserQuestion):

"Where should alerts be sent?"

Options:

1. Email -- Simple, always available
2. Slack/Teams webhook -- Team visibility
3. PagerDuty/OpsGenie -- On-call rotation and escalation
4. SMS -- Critical alerts only

Expert: Allow full customization of thresholds, metrics, and notification channels per alert.

Intermediate: Present defaults and allow adjustments: "Here are the recommended alert thresholds. Would you like to adjust any?"

Beginner: Apply defaults: "I'll set up alerts for the most critical conditions. You'll receive notifications at [chosen channel] when your services need attention."

Step 6: Generate Monitoring IaC

Invoke the arn-infra-specialist agent via the Task tool, passing the model from .arness/agent-models/infra.md as the model parameter (see plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

--- MONITORING CONTEXT --- Observability stack: [chosen stack] Provider: [provider] Environments: [list] Deployed resources: [from resource manifest, or "not yet deployed"] --- END MONITORING CONTEXT ---

--- LOGGING CONFIGURATION --- Log format: structured (JSON) Log destinations: [provider-native service] Retention: [per-envi