/arn-infra-monitor

name: arn-infra-monitor
description: >-
  This skill should be used when the user says "set up monitoring", "arn infra monitor",
  "infra monitor", "configure monitoring", "set up observability", "add logging",
  "configure alerting", "set up alerts", "infrastructure monitoring", "add metrics",
  "set up cloudwatch", "configure grafana", "observability setup", "logging setup",
  "alerting setup", "health checks", "monitor infrastructure", "arn-infra-monitor",
  "set up cloud monitoring", "configure notifications", "prometheus", "datadog",
  "new relic", "sentry", or wants to set up logging, metrics collection, and
  alerting for their deployed infrastructure.
version: 1.0.0

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 f