Merge pull request 'Kuma: a fact per monitor, so she can name the service that is down' (#147) from task/444-kuma-a-fact-per-monitor-so-she-can-name into master

This commit was merged in pull request #147.
This commit is contained in:
2026-08-04 18:24:47 +02:00
19 changed files with 526 additions and 100 deletions
+23
View File
@@ -424,6 +424,29 @@ lives in `source`; rules trust provenance.
`source=poll:healthcheck`. A compromised poller must not be able to forge a
trigger.
#### A fact per monitor, not an aggregate
mavpoll writes one fact per kuma monitor, keyed `service_down:<monitor name>`.
It used to fold the whole gauge into a single boolean, and the nudge could then
only say that something on homesrv was down. That is not something he can act
on, so the rule shipped disabled.
Three things follow from the split:
- The key set is no longer known at wiring time. A rule declares
`WantPrefixes` and the gatherer resolves the family per tick, which is the
only prefix read in the loop.
- Pausing a monitor in kuma silences that monitor. Under the aggregate it
silenced nothing, because some other monitor kept the boolean at "down".
- A monitor deleted in kuma would keep its last fact reading "down" forever, so
mavpoll marks a vanished monitor "unknown". No rule fires on "unknown".
The rule is also edge-triggered: it fires on a transition it has not already
nudged about (`State.NudgedSince`). A polled fact is written only when the
value changes, but the predicate reads the current value, so without the edge
check a service that stays down qualifies on every tick and cooldown is the
only brake.
### Presence — concrete scoring
**Combiner — noisy-OR, not weighted sum.** These are independent-ish positive