zara-healthcheck: passive machine, network and service health monitor #19

New issue

Closed

opened 2026-08-31 18:44:56 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-31 18:44:56 +00:00

(Migrated from github.com)

Plugin

zara-healthcheck

Goal

Provide Zara with a lightweight passive health-monitoring plugin for machine, network and service status. This is the observability/watch layer; diagnosis/remediation belongs in zara-sysadmin.

Initial signals

CPU/load/memory pressure;
disk usage and inode pressure;
GPU availability/utilization/temperature where supported;
network reachability/interface state;
DNS probe state;
configured TCP/HTTP/service health checks;
systemd service state where available;
battery/power/thermal signals where available;
configurable threshold/rule evaluation.

Behavior

periodic bounded probes with jitter/backoff;
retain current state plus a bounded recent history;
emit structured health-state-change events;
distinguish healthy/degraded/unhealthy/unknown;
avoid alert spam through deduplication/hysteresis;
optionally hand unhealthy facts to zara-sysadmin for diagnosis.

Safety / reliability

probes are read-only;
network targets must be configured/explicit;
bounded concurrency/timeouts/history;
failed probes produce unknown/failure evidence rather than fabricated status;
no remediation actions in this plugin.

Acceptance criteria

normalized health/check/result model exists
local resource and configured network/service probes are representable
state-change events and bounded history exist
dedupe/hysteresis prevents repeated identical alerts
unhealthy results can be exported as structured facts for zara-sysadmin
tests use fake clocks/probes and require no network/root
README documents probe configuration and status semantics
registry validation, plugin tests and nix flake check pass

## Plugin `zara-healthcheck` ## Goal Provide Zara with a lightweight passive health-monitoring plugin for machine, network and service status. This is the observability/watch layer; diagnosis/remediation belongs in `zara-sysadmin`. ## Initial signals - CPU/load/memory pressure; - disk usage and inode pressure; - GPU availability/utilization/temperature where supported; - network reachability/interface state; - DNS probe state; - configured TCP/HTTP/service health checks; - systemd service state where available; - battery/power/thermal signals where available; - configurable threshold/rule evaluation. ## Behavior - periodic bounded probes with jitter/backoff; - retain current state plus a bounded recent history; - emit structured health-state-change events; - distinguish healthy/degraded/unhealthy/unknown; - avoid alert spam through deduplication/hysteresis; - optionally hand unhealthy facts to `zara-sysadmin` for diagnosis. ## Safety / reliability - probes are read-only; - network targets must be configured/explicit; - bounded concurrency/timeouts/history; - failed probes produce `unknown`/failure evidence rather than fabricated status; - no remediation actions in this plugin. ## Acceptance criteria - [ ] normalized health/check/result model exists - [ ] local resource and configured network/service probes are representable - [ ] state-change events and bounded history exist - [ ] dedupe/hysteresis prevents repeated identical alerts - [ ] unhealthy results can be exported as structured facts for `zara-sysadmin` - [ ] tests use fake clocks/probes and require no network/root - [ ] README documents probe configuration and status semantics - [ ] registry validation, plugin tests and `nix flake check` pass