Kuma: a fact per monitor, so she can name the service that is down #147

Merged
claude merged 4 commits from task/444-kuma-a-fact-per-monitor-so-she-can-name into master 2026-08-04 18:24:48 +02:00

4 Commits

Author SHA1 Message Date
claude 6d8a95095a deploy, docs: turn service_down back on (V-444)
It was disabled because it could not say which service. It can now.
2026-08-04 05:15:02 +04:00
claude 7e21cd06b3 phraser: name the service that is down (V-444)
Stub and LLM paths both read loop.DownServices, so the message can never name
a service the predicate did not fire on. Two down at once are both named — he
needs the blast radius.
2026-08-04 05:15:01 +04:00
claude 09c648b934 mavpoll: write one kuma fact per monitor (V-444)
The aggregate could not name the service, which is the whole reason the nudge
said 'a service on homesrv is down' and the rule shipped disabled.

A monitor deleted in kuma stops appearing in the gauge and its last fact would
read down forever, so a vanished monitor is marked unknown. Pending and
maintenance are not down: a monitor paused in kuma now silences that monitor
rather than nothing.
2026-08-04 05:15:01 +04:00
claude 4f516657da loop, store: read a fact family by prefix (V-444)
A rule over a key set that only exists at read time cannot declare its keys
at wiring time. Kuma has one monitor per service and the names live in the
gauge, so the rule declares a prefix and the gatherer resolves the family per
tick.

ServiceDownRule now fires on any monitor reading down, names it through
DownServices, and is edge-triggered: a service that stays down is one nudge,
not one per tick with cooldown as the only brake.
2026-08-04 05:14:50 +04:00