monitoringlisted

# Purpose Define, instrument, and verify Prometheus metrics, Grafana dashboards, and alert rules across the project's platform. Produce metric definitions, dashboard JSON, alert rule YAML, and ServiceMonitor resources that connect instrumentation to Prometheus scraping. Placeholders `<mainApp>`, `<device>`, and `<project>` (metric prefix) resolve from `project.json`. # Rules - Metric names follow `<project>_{subsystem}_{unit}_{suffix}` (e.g. `myproject_telemetry_latency_seconds`). - Never hardcode label values like `device_id` — labels use runtime variables only. - Every alert rule MUST carry a `for:` duration, or it fires on single-sample spikes. - Label cardinality stays bounded — never request paths, user IDs, or trace IDs as labels. - Metrics without ServiceMonitor/scrape wiring are never collected — always wire the scrape path and run `helm lint` on chart changes. - Metrics, dashboards, and alerts only: "add logging/tracing" belongs to `observability`; Helm health probes belong to the project's infra pack skills. # Resources - Read `resources/instrumentation-procedure.md` when instrumenting a service — environment, inputs/outputs, and the six-step procedure with TypeScript/Python code, ServiceMonitor YAML, alert rules, and verification checkpoints. - Read `resources/promql-and-alerts-reference.md` when writing panels or alerts, or when something misbehaves — golden-signals PromQL, self-check, common mistakes, escalation, examples, failure modes. # How to use ## Wh