Description
The health dashboard visualizes tailscale2otel.receiver.misconfigured, but no rule watches it. A non-zero value means an enabled network receiver is rejecting every input with HTTP 403 until the operator supplies its credential or binds it safely; this is low-noise and directly actionable.
Acceptance Criteria
- #1 A generated advisory non-paging rule detects receiver.misconfigured above zero per receiver for a sustained 10-minute window
- #2 The rule remains quiet when the receiver is disabled and has executable Prometheus fixtures covering fire and healthy cases
- #3 Grafana-managed and Prometheus artifacts plus runbook documentation regenerate, deploy successfully, and verify in sync
Definition of Done
- #1 just check passes (the full gate; it is what CI enforces)
- #2 just gen leaves no diff (only if a generated artifact’s inputs changed)
- #3 just –fmt –check passes and every new recipe has a # doc comment and a [group(…)]
Implementation Notes
Done in 7841543f. ts2o-receiver-fail-closed: max by (receiver) (tailscale2otel_receiver_misconfigured_ratio) > 0 for 10m, severity advisory, no page label, policy optional so a disabled receiver’s absence stays Ok while a datasource error surfaces as Error. Runbook ingest-receivers, panel ‘Fail-closed receiver misconfiguration’. The 10m window keeps a rolling restart quiet. Fixtures cover a receiver reporting 0 (healthy, not absent, since the point of the signal is that the exporter is healthy while one route accepts nothing) and a sustained 1. Negative-tested on its own: threshold moved to 999, the fixture failed, reverted. Pushed live with gcx –context m7kni; verify-deploy m7kni reports 133 shipped, 133 deployed, 0 missing, 0 orphaned, 0 drifted.